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DISCLAIMER 


Opinions,  conclusions,  and  recommendations  expressed  or  impLied 
within  are  solely  those  of  the  author,  and  do  not  necessarily  represent 
the  views  of  the  National  Defense  University,  the  Department  of  Defense, 
or  any  other  Government  agency,  or  any  private  organization. 

Material  for  this  study  was  collected  largely  from  existing  doc- 
umentation (Selected  Acquisition  Reports  (SAR’s),  Command  Review  and 
Assessment  of  Projects  (RECAP's),  and  Historical  Summaries)  supplemented 
by  extensive  personal  interviews  with  personnel  currently  and  previously 
associated  with  the  TACFIRE  program,  both  on  the  government  and  contractor 
sides.  In  the  interest  of  obtaining  as  much  information  as  possible  to 
make  this  a useful  document,  all  interviews  were  conducted  on  a "not  for 
attribution"  basis. 
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THE  MAKING  OF  A WEAPON  SYSTD.l: 


TACFIRE  1959-1978 


I.  INTRODUCTION 


For  almost  twenty  years,  the  Army  has  been  seeking  to  apply  a 
significant  degree  of  automation  to  the  Field  Artillery  function. 

It  now  appears  probable  that  a full  scale  production  go-ahead  for 
the  Tactical  Fire  Direction  System  (TACFIRE)  will  be  obtained  in 
1978,  with  systems  going  to  field  artillery  units  soon  thereafter. 

Why  has  this  process  taken  so  long?  Is  the  Army  guilty  of 
mismanagement?  Are  the  contractors  at  fault?  While  there  are  no 
simple  answers,  this  case  study  will  look  back  over  the  TACFIRE 
acquisition  history  and  attempt  to  provide  the  reader  with  some 
insight  into  both  the  technical  and  managerial  issues  that  have 
influenced  the  lengthy  development  history  of  this  system. 

Many  "lessons  learned"  have  come  out  of  the  TACFIRE  program. 
Unfortunately,  lessons  learned  too  often  become  lessons  forgotten. 
The  Army  falls  short  in  its  ability  to  retain  a corporate  memory 
and  as  a consequence  is  frequently  doomed  to  repeating  its  past 
mistakes.  Only  those  items  that  eventually  rise  to  the  level  of 
enforced  policy  or  regulation  seem  to  achieve  the  necessary 
visibility  and  gain  attention  of  managers  and  supporting  staffs 
to  effect  enduring  change  and  improved  ways  of  doing  business. 

Many  other  experiences  and  ideas  lie  fallow  in  the  project  files 
or  go  completely  undocumented.  This  study  of  TACFIRE  is  written 
with  the  hope  that  the  acquisition  system  can  be  improved  as  a 
result  of  the  TACFIRE  experience  and  that  future  project  managers 
and  their  staffs  concerned  with  the  acquisition  of  computer-based 
Systems  can  continue  to  benefit  from  that  experience. 

It  is  not  feasible  in  one  short  document  to  provide  an  exhaustive 
study  of  the  entire  TACFIRE  development  program.  Rather,  the  princi- 
pal emphasis  of  this  study  is  on  the  software  development  aspect  of 
the  system.  To  put  this  into  proper  perspective,  major  elements  of 
the  overall  development  program  will  be  presented  as  well., 

' \ 

II . BACKGROUND 


Establishing  the  Requirement 

The  first  significant  efforts  aimed  at  applying  automation  to 
the  battlefield  began  in  the  late  1950s.  The  US  Army  Electronics 
Laboratories  at  Fort  Monmouth,  New  Jersey,  were  developing  a family 
of  digital  computers  for  military  applications.  The  FIELDATA  systems. 
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as  they  were  known,  were  being  developed  in  a variety  of  configura- 
tions as  general  purpose  militarized  computers  capable  of  handling 
a variety  of  applications.  Already,  functional  proponents  were 
studying  the  potential  applications  of  ADP  to  their  areas.  In 
particular,  the  US  Army  Artillery  and  Missile  School  (USAAMS) 
developed  an  early  Qualitative  Materiel  Requirement  (QMR)  for  a 
Fire  Support  Sub  System  in  1959 . 

A series  of  "fire  planning  memoranda"  were  intiated  by  USAAMS 
in  I960,  with  contractual  support  for  software  development  from 
Bunker  Ramo,  under  the  management  of  the  Army  Electronic  Proving 
Grounds,  at  Ft.  Huachuca,  AZ.  These  early  memoranda  requirements 
resulted  in  WHITE  PLAN  I,  a system  concept  (using  a commercial  IBM, 

7090  computer)  demonstrated  to  DA  and  other  service  representatives 
to  establish  the  feasibility  of  automating  field  artillery  Amotions. 
To  reinforce  the  concept,  additional  memoranda  and  software  develop- 
ments were  added  and  demonstrated  in  WHITE  PLAN  II  during  March  of 
1961.  By  this  time,  the  feasibility  of  automating  the  field 
artillery  function  had  been  well  established. 

Acting  in  response  to  a directive  from  the  Department  of  the 
Army , the  USACONARC  directed  the  US  Army  Command  and  General 
College  to  prepare  a plan  to  integrate  ADP  into  the  field  Army  command 
information  systems.  With  the  assistance  of  several  agencies,  the 
U5AC&GSC  prepared  a comprehensive  plan  under  the  title  "Command 
Control  Information  Systems  1970"  (CCIS70).  Following  USACONARC 
approval,  the  plan  was  sent  to  DA  where  it  was  formally  approved  on 
3 January  1962  as  the  basic  DA  planning  document  for  developing  ADP 
systems  for  the  field  Army. 

A reorganization  of  the  Army  in  1962  vested  user  responsibility 
for  fire  support  requirements  with  the  Field  Artillery  Agency  (FAA) 
of  the  new  US  Army  Combat  Developments  Command.  While  the  Electronics 
Lab'  ratorie.’  continued  work  on  equipment  development,  the  US  Army 
Electronic  Pr  vine  Ground  at  Fort  Huachuca  had  been  tasked  to  develop 
and  e.'t  ADP  systems  under  field  conditions.  A new  series  of  highly 
detailed  fire  .ujpjmrt  memoranda  were  then  developed  under  contract, 
wi‘:,  . -inker  Ham1  . An  Engineering  Design  Test,  followed,  testing 
•i T.r'.e  thread  apj  li ••at. ions  programs  one  at  a time.  While  this  test 
■‘rated  * h-  practicality  of  automa'ion  of  most  of  the  major 
artillery  l’uncti  n.:,  it  did  not  combine  the  individual 
i -a*  ! r,  ii  • a per  totype  Integrated  system. 

••  :M  r<  - ,p;  r*  f it  -tion  wn  tie  of  five  tactical  command  and 

no  tie-  Amy  was  examining  as  candidates  for  automation, 
ler  - 1 in  • a le  i intelligence,  operati  ns,  personnel  and 
i ail  f which  had  been  addressed  in  the  earlier  CCIS-7C 
ter  DA  ilrection,  the  Command  and  Control  Information 
■r  up  f within  the  Combat  Developments  Command)  updated  the 
'•■a  I crrs-70  plan  and  produced  an  Implementation  Plan  for  Auto- 
mata .’yst.ems  within  the  Army  in  the  field  (ADSAF).  This  plan 


developed  during  1964  and  early  1965,  realigned  the  tactical  systems 
to  be  developed  into  a Tactical  Fire  Direction  System  (TACFIRE),  a 
Tactical  Operations  System  (TOS),  including  both  intelligence  and 
operations,  and  a Combat  Service  Support  System  (CS^)  which  combined 
personnel  and  logistics. 

Following  DA  approval  of  the  implementation  plan  in  May  1965, 
project  management  responsibility  for  the  three  ADSAF  systems  was 
vested  in  a new  Automatic  Data  Field  Systems  Command  (ADFSC)  at 
Fort  Belvoir.  The  ADFSC  evolved  from  the  earlier  CDC  Group  and  CCIS-70 
and  reported  both  to  the  Army  Materiel  Command  as  a materiel  developer 
and  the  Combat  Developments  Command  as  a combat  developer.  Military 
systems  directors  (0-6)  for  each^  of  the  major  systems  reported  to 
the  Commanding  General/Project  Manager.  Meanwhile,  the  user  role 
continued  to  be  fulfilled  by'  the  Field  Artillery  Agency  (FAA),  and 
technical  (hardware)  support  to  the  PM  was  furnished  by  the  Electron- 
ics Laboratories  under  the  US  Army  Electronics  Command  (ECOM)  at  Fort 
Monmouth . 

Included  in  the  ADSAF  Implementation  Plan  was  a set  of  formats 
proposed  for  documenting  requirements  for  tactical  ADP  systems,  called 
Functional  System  Design  Requirements  (FSDR).  With  the  assistance  of 
Bunker  Ramo,  the  FAA  took  the  series  of  fire  support  memoranda 
together  with  the  documented  software  developed  earlier  and  the  test 
results  from  the  White  Plan  and  Engineering  Design  Tests  and  wrote  a 
set  of  FSDR’s  which  were  eventually  to  become  the  basis  for  the 
TACFIRE  specifications. 

It  was  now  necessary  to  bring  the  FSDR  and  QMR  into  agreement.  To 
accomplish  this  some  tradeoffs  had  to  be  made.  The  original  QMR  called 
for  fire  support  (TACFIRE)  systems  at  Division  Artillery  (DivArty), 
Battalion,  Fire  Support  Element  ( FSE ) and  Battery  levels.  The  ADSAF 
Plan  had  dropped  out  the  FSE  and  Battery  systems  so  they  were  thus 
eliminated  from  the  QMR.  In  addition,  input/output  terminal  devices 
were  also  deleted  for  the  liaison  officer,  survey,  and  meteorological 
teams. 

A new  DA  approved  QMR  for  "TACFIRE  of  ADSAF"  was  thus  promulgated 
in  early  1966  as  the  culmination  of  several  years  of  effort  aimed  al 
establishing  the  feasibility  of  automation  of  field  artillery  functions 
and  maturing  the  requirement.  A formal  project  management  office  had 
now  been  established  along  with  an  effective  users'  representative 
organization.  When  the  comparative  state-of-the-art  of  commercial 
data  processing  in  the  late  1950s  to  early  1960s  is  considered  along 
with  the  cultural  shock  of  automating  real  time  tactical  military 
functions,  it  is  difficult  to  see  how  this  process  could  have  been 
shortened  to  any  significant  degree  by  the  Army. 

1 

Originally  TOS  and  TACFIRE  were  combined,  but  later  split  into 

separate  divisions. 


3 


TACFIRE  Defined 


Before  going  further  into  the  development  history,  it  would  be 
useful  at  this  point  to  define  in  brief  what  TACFIRE  was  to  be  as  a 
result  of  the  requirement  refinement  process  described  above. 

TACFIRE  is  a system  which  applies  automatic  data  processing 
techniques  to  the  seven  field  artillery  functions  of  technical  fire 
control,  tactical  fire  control,  fire  planning,  artillery  target 
intelligence,  artillery  survey,  meteorological  data,  and  ammunition 
and  fire  unit  status.  It  also  provides  a capability  for  preliminary 
target  analysis,  nuclear  target  analysis,  nuclear  fire  planning, 
chemical  target  analysis,  and  fallout  prediction. 

To  perform  these  functions,  TACFIRE  computer  centers  are  to  be 
located  at  DivArty  and  at  each  direct  support  (DS)  and  general  support 
(GS)  firing  battalion.  Centers  similar  to  the  DivArty  center  may 
also  be  found  at  Corps  Artillery  and  Field  Artillery  Groups.  The 
heart  of  each  center  is  a medium  scale  militarized  digital  computer 
and  associated  memory  mounted  in  one  or  two  S-280  shelters  on  a truck. 
Each  center  includes  local  input/output  devices  for  control  of  the 
system  by  field  artillery  personnel. 

At  the  battalion  centers,  an  Artillery  Control  Console  enables  the 
computer  operator  to  input  data  rapidly  to  the  system  and  retrieve 
information  from  it.  For  example,  Fire  missions  received  from  forward 
observers  can  be  reviewed,  and  computed  fire  orders  released  to  the 
batteries  with  provisions  for  approvals  and  modifications.  A medium 
speed  printer  provides  hard  copy  of  all  transactions  while  a Digital 
Plotter  Map  provides  a four  foot  by  four  foot  visual  display  of  the 
tactical  situation  on  standard  military  maps. 

The  DivArty  Center  has  similar  equipment  plus  an  Electronic 
Tactical  Display  (Cathode  Ray  Tube,  or  CRT)  which  electronically 
augments  the  Digital  Plotter  Map.  Each  firing  battery  is  equipped 
with  a printer,  the  Battery  Display  Unit,  to  receive  firing  data  and 
other  information  from  battalion.  Remote  input/output  devices  enable 
forward  observers,  fire  support  officers  and  others  to  communicate 
with  TACFIRE  using  standard  tactical  radios  or  wire  and  authentication 
techniques  to  provide  a degree  of  security.  Security  for  most  of  the 
links  is  provided  by  cryptographic  devices.  • 

Virtually  all  of  the  hardward  devices  described  above  are  general 
purpose.  They  are  tailored  to  the  TACFIRE  function  through  "software," 
the  detailed  computer  programs  which  control  their  operation.  Multiple 
applications  programs  are  required  for  each  type  computer  center  to 
accomplish  the  seven  major  functions  described  earlier.  A more  detailed 
list  of  these  programs  and  their  functions  is  provided  in  Appendix  A. 

Besides  the  applications  programs,  two  other  types  of  software  are 
required.  Maintenance  and  Diagnositic  programs  are  used  to  verify  proper 


system  functioning  and  to  locate  faulty  circuit  cards  or  assemblies 
when  malfunctions  occur.  Finally,  the  most  critical  element  of  the 
software  is  the  Operating  System  (OS)  which  controls  TACFIRE,  hardware 
and  software,  and  integrates  all  of  the  many  hardware  and  software 
elements  into  a cohesive  system. 

This,  then,  is  an  overview  of  the  system  the  Army  set  out  to 
develop  and  acquire  following  several  years  of  requirements  determin- 
ation in  the  mid-1960s.  The  reader  should  appreciate  that  this  was 
an  exceptionally  ambitious  undertaking  in  that  time  frame.  Real-time 
systems  (i.e.,  systems  whose  performance  are  event  driven  with 
critical  required  response  times  rather  than  schedule  driven)  were 
not  easily  developed  for  the  commercial  world  let  alone  for  a battle- 
field environment,  and  this  system  was  quite  complex.  Neither  the 
militarized  hardware  nor  the  unique  software  existed  at  the  time, 
and  hence  both  would  have  to  be  developed  concurrently. 

III.  CONTRACT  DEFINITION  PHASE 

With  the  approval  of  the  Director  of  Defense  Research  and  Engineer- 
ing (DDR&E),  a competitive  "Contract  Definition  Phase"  was  begun  in 
1966.  Industry  was  invited  to  bid  on  a contract  which  would  lead 
eventually  to  a design  for  an  integrated  TACFIRE.  Subsequent  guidance 
from  the  Army  indicated  that  multiple  contracts  would  be  awarded,  but 
restricted  the  bidding  to  prime  contractors  who  were  computer  mainframe 
manufacturers.  This  late  restriction  caused  some  turbulence  among  the 
industry  teams  which  were  prepared  to  submit  proposals.  In  one  case, 
the  prime  contractor/subcont  -actor  relationship  between  teamed  companies 
had  to  be  reversed  as  a result. 

The  imposition  of  the  requirement  that  prime  contractors  be  mainframe 
manufacturers  may  be  indicative  of  an  early  misconception  about  tactical 
data  systems  on  the  part  of  the  Army.  In  effect  It  reflected  a viewpoint 
that  TACFIRE  was  first  and  foremost  to  be  a set  of  hardware  machines.  In 
fact,  however,  it  will  be  seen  that  while  the  hardware  was  not  free  from 
problems,  software  problems  were  to  dominate  the  picture  completely, 
followed  by  problems  in  overall  hardware/software  system  integration.  A 
recognition  of  the  criticality  of  software  might  have  removed  this 
restriction  and  permitted  a better  set  of  proposals  to  be  submitted. 

A Source  Selection  Evaluation  (SSEB)  Board  met  at  Letterkenny 
Army  Depot  for  approximately  six  weeks  in  January  of  1967  to  consider 
five  proposals  for  the  Contract  Definition  phase.  Subsequently,  in 
March  of  that  year,  three  contracts  were  awarded  to  IBM  (Federal  Systems 
Division),  Burroughs  (Defense  Space  and  Special  Systems  Group),  and 
Litton  Industries  (Data  Systems  Division),  all  for  in  excess  of  $1 
million  each  ($3.7M  total).  The  study  efforts  were  to  last  approximately 
[ twenty  weeks  resulting  in  a preliminary  specification  for  TACFIRE  (based 

on  the  FSDRs),  as  well  as  a technical  approach  to  the  system  development 
including  the  contractor's  recommendation  as  to  the  best  language  for 
developing  the  tactical  software. 
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The  three  contractors  submitted  the  results  of  their  study  efforts 
and  it  now  fell  to  the  Army  to  select  the  best  of  the  three  for 
proceeding  into  actual  development.  The  same  Source  Selection  Evalu- 
ation Board  reconvened  in  August  of  1967  to  consider  the  three  proposals. 
After  approximately  another  six  weeks,  they  reached  the  recommendation 
that  Litton  be  awarded  the  follow-on  effort. 

It  is  important  to  understand  that  the  contractor's  proposal  was 
to  be  the  basis  for  the  specifications  for  the  follow-on  effort.  Some 
on  the  Government  side  have  criticized  the  SSEB  for  not  adequately 
comparing  the  contractor's  proposal  to  the  FSDR  documents,  although 
late  in  the  evaluation  period  a special  effort  was  directed  at  this. 
Future  determinations  of  items  falling  within  the  scope  of  the  contract 
or  out -of -scope  would  have  to  be  made  on  the  basis  of  the  specifications 
as  they  appeared  in  the  contract,  regardless  of  the  content  of  the 
FSDRs.  This  eventually  was  to  become  a source  of  many  problems  for  the 
Army. 

IV.  TACFIRE  DEVELOPMENT 


Development  of  TACFIRE  was  formally  begun  in  December  of  1967  with 
the  award  of  the  prime  contract  to  Litton  Industries.  Litton  in  turn 
had  teamed  with  two  subcontractors  to  assist  in  the  software  develop- 
ment work.  These  were  Planning  Research  Corporation  (PRC)  and  Infor- 
matics. 

A unique  feature  of  the  Litton  contract  was  that  it  was  the  first 
award  by  the  Army  of  a Total  Package  Procurement  ( TPP ) type  contract 
which  covered  not  only  development  but  subsequent. production  as  well. 
Total  value  of  the  contract  was  a ceiling  of  $122. 3M,  including  both 
R&D  and  production.  One  of  the  major  reasons  for  awarding  a TPP 
contract  was  the  earlier  unfavorable  experience  the  Army  had  had  with 
the  FADAC  computer  when  production  was  awarded  to  a contractor  other 
than  the  developer,  and  major  problems  arose  when  one  contractor 
attempted  to  manufacture  the  FADAC  based  on  the  design  package  produced 
by  another.  The  TPP  concept  in  effect  ruled  out  future  competition 
for  production  of  the  TACFIRE  system.  It  also  was  designed  to  preclude 
"buy-in"  by  a contractor  for  the  R&D  phase  with  subsequent  catch-up 
during  production. 

The  original  TPP  TACFIRE  contract  with  Litton  was  extremely 
ambitious.  The  entire  span  of  the  contract  was  for  69  months,  with 
the  first  systems  to  be  delivered  to  the  Army  for  testing  at  the  end 
of  the  first  22  months.  This  is  probably  indicative  of  a considerable 
degree  of  naivete  at  that  time  on  both  the  part  of  the  Government  and 
of  the  contractor. 

A significant  aspect  of  the  TPP  contract  also  was  the  incentive 
structure  which  it  contained.  Incentives  were  included  based  on  cost, 
schedule,  and  system  performance.  The  latter  was  to  be  determined  on 
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the  basis  of  a mathematical  formula  (developed  by  a separate  contract) 
including  various  measurable  system  response  times.  One  of  the 
factors  in  the  formula  included  a logarithm  function  which  was  origin- 
ally unspecified  (probably  due  to  a typographical  error)  as  to 
whether  it  should  be  the  natural  log  (base  "e")  or  common  log  (Base  10). 

At  a subsequent  meeting,  the  word  "natural"  was  inserted.  While  this 
may  at  first  seem  inconsequential,  it  had  the  effect  of  multiplying 
the  performance  incer - ive  factor  by  more  than  2,  and  as  a result  the 
performance  incentive  to  the  contractor  completely  dominated  cost 
and  schedule  considerations.  With  such  a weighting,  it  is  clear  that 
a contractor  will  opt  for  improved  system  performance  at  the  expense 
of  increased  cost  and  stretched  out  schedule  whenever  a tradeoff  is 
to  be  made  because  it  is  in  his  financial  interest  to  do  so, 
especially  when  a $17M  incentive  was  at  stake  as  in  this  case. 

A number  of  different  players  were  now  on  the  scene  at  various  lo- 
cations. The  Army  project  manager  in  name  was  the  Commanding  General 
of  the  Automatic  Data  Field  Systems  Command;  in  fact,  the  TACFIRE 
Director  within  the  ADFSC  organization  generally  exercised  the  PM 
authority  with  a staff  of  about  10  people  located  at  Fort  Belvoir,  VA. 
Technical  support  to  the  PM  (primarily  on  hardware)  came  from  the 
Electronic  Laboratories  at  Fort  Monmouth,  NJ.  The  Combat,  Developments 
Command's  Field  Artillery  Agency  at  Fori.  Sill  represented  the  user. 

Also,  the  Artillery  Center  and  School  at  Fort.  Sill  had  an  interest  in 
monitoring  the  development  effort.  At  Fort  Huachuca,  AZ,  a Cost,  Oper- 
ational Effectiveness  Analysis  (COEA)  group  was  charged  with  doing 
a COEA  on  TACFIRE.  Finally,  the  Field  Artillery  Board  was  concerned 
with  testing  the  system. 

A significant  PM  decision  resulted  in  the  establishment  of  a 
Government  resident  development,  office  at  the  Litton  plant,  in  Van  Nuys, 

CA  early  in  1968.  The  PM  on-site  team  was  headed  by  a military  0-5  (later 
0-6),  with  a civilian  deputy  and  a three  man  software  group.  These  were 
to  be  joined  shortly  by  representatives  from  the  FAA,  the  Artillery  School. 
TECOM,  and  the  ECOM  laboratories,  all  as  essentially  independent  repre- 
sentatives. 

Software  development  quickly  became  the  pacing  item  of  the  system. 
Management  of  the  software  effort  was  complicated  by  the  fact  that  three 
different  software  development  teams  were  involved.  Litton,  the  prime 
contractor,  retained  some  development  responsibilities  to  enhance  its 
internal  capabilities.  Their  in-house  team  took  on  the  task  of  developing 
the  operating  system  as  well  as  the  DivArty  and  Battalion  applications 
programs.  FSE  applications  programs  were  subcontracted  to  Planning 
Research  Corporation  (PRC),  while  Informatics  was  responsible  for  support 
software,  including  implementation  of  a new  high  level  programming 
language  called  TACPOL,  designed  by  PRC.  The  split  of  applications 
programs  between  Litton  and  PRC  would  require  careful  coordination 
because  the  programs  were  interrelated. 


( 
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Management  control  from  the  Government  point  of  view  was  to  be 
maintained  through  a series  of  reviews,  but  no  intermediate  formal 
deliverable  items  were  included  prior  to  the  actual  system  deliveries. 
The  acquisition  process  at  that  time  called  for  Research  and  Development 
Acceptance  Tests  (RDAT)  at  the  contractor's  facilities  followed  by 
Engineering  Tests  and  Serviceability  Tests  ( ET/ST ) in  a field  environ- 
ment . 

The  first  formal  review  scheduled  was  a Preliminary  Design  Review 
(PDR)  planned  for  the  summer  of  1968.  For  a number  of  reasons  this 
review  was  not  held  until  December  of  1968.  A major  problem  turned 
out  to  be  differences  of  opinion  over  what  the  contract  called  for  in 
the  software.  The  FSDR  documents  were  the  primary  source  documents 
from  the  user's  point  of  view,  but  they  were  not  part  of  the  contract. 

To  confuse  matters  further,  the  extensive  set  of  detailed  specifications 
that  had  been  developed  during  the  contract  definition  phase  were  not 
formally  part  of  the  contract,  since  they  had  not  been  signed  by  either 
party.  The  only  software  specifications  formally  included  in  the  con- 
tract amounted  to  a relatively  brief  overview  specification  set  which 
left  a great  deal  of  room  for  disagreement  between  the  contractor  and 
the  Government. 

Prior  to  the  formal  PDR,  the  field  artillery  representatives 
undertook  a detailed  review  of  the  specifications  and  the  eontrac+  and 
generated  nearly  1000  comments  ranging  from  minor  corrections  co  rious 
deficiencies  which  would,  as  they  saw  it,  nullify  the  effectiveness 
of  TACFIRE.  Discussions  on  these  items  became  confusing  due  to  the 
multiple  parties  involved  both  on  the  Government  side  (PM,  FAA, 

Artillery  School)  and  the  contractor's  side  (prime  and  subs).  Official 
agreements  could  only  be  made  between  the  FM/contracting  officer  and 
Litton  as  the  prime  contractor,  but  the  other  parties  were  deeply  con- 
cerned as  well.  It  appears  that  there  was  a great  reluctance  on  the 
part  of  the  PM  office  to  make  any  changes  beyond  those  which  would 
correct  obvious  errors.  In  fact,  no  changes  had  been  programmed  for 
in  the  TACFIRE  budget.  Further,  the  PM  office  was  heavily  schedule 
oriented.  Any  major  changes  would  involve  both  dollars  and  time, 
requiring  Department  of  the  Army  approval.  According  to  some  who  were 
involved,  major  cost/schedule  changes  may  well  have  resulted  in  the 
death  of  TACFIRE  as  the  PM  saw  it. 

Nevertheless  it  soon  became  obvious  to  a number  of  people  that 
the  schedule  called  for  by  the  contract  was' totally  unrealistic, 
especially  as  far  as  software  was  concerned.  It  would  be  fair  to  say 
that  both  the  Government  and  the  contractor  lacked  the  proper  depth 
of  qualified  software  developers  and  managers,  and  naivete  prevailed. 

The  first,  obvious  evidence  of  slippages  was  the  delay  of  the  PDR  until 
December  of  68. 


Besides  the  lack  of  appreciation  for  the  time  it  would  take  to 
develop  the  software,  inaccurate  estimates  of  software  size  (numbers 
of  instructions)  led  to  gross  underestimation  of  memory  requirements. 


The  initial  estimates  were  carried  over  from  the  Engineering  Design 
Test  effort  under  Bunker  Ramo.  As  a result,  extensive  hardware  changes 
would  later  be  required  to  provide  sufficient  on-line  storage  capacity. 

It  may  be  that  some  foresaw  the  probability  of  increased  memory 
requirements;  if  so,  such  considerations  were  dismissed  due  to  their 
obvious  cost  impact. 

Of  the  approximately  1000  deficiencies  cited,  Litton  accepted 
the  majority,  the  Government  withdrew  nearly  200,  and  eventually  less 
than  20  became  matters  of  contention.  A baseline  software  specifica- 
tion set  finally  was  arrived  at  following  the  December  1968  PDR.  All 
was  not  to  proceed  smoothly  from  this  point,  however. 

It  should  be  noted  that  another  change  in  the  Army  project 
management  structure  had  taken  place  during  this  time  frame.  The 
Automatic  Data  Field  Systems  Command  was  supplanted  by  the  new  Computer 
Systems  Command.  From  the  point  of  view  of  TACFIRE,  this  change  was 
largely  cosmetic  in  that  the  TACFIRE  Directorate  continued  to  manage 
the  program.  The  new  CSC  organization  took  on  responsibility  for 
non- tactical  multi-command  data  systems  in  addition  to  the  ADSAF  program, 
however.  This  broadened  the  scope  of  responsibilities  of  the  CG/PM  and 
necessitated  further  decentralization  of  TACFIRE  responsibility  to  the 
system  director. 

Research  and  Development  Acceptance  Testing  (RDAT) 


Litton  had  originally  estimated  that  RDAT  would  begin  18  months 
after  award  of  contract  and  last  about  5 months.  The  Government 
development  estimate  similarly  called  for  completion  of  RDAT  in  October 
of  1969.  RDAT  did  not  actually  begin  until  February  of  1970.  It  lasted 
just  over  two  years,  terminating  in  March  of  1972  putting  the  program 
almost  two  and  half  years  behind  schedule. 

The  reasons  behind  this  significant  slippage  are  many,  several 
of  which  have  already  been  discussed  such  as  the  gross  underestimation 
by  all  concerned  of  the  magnitude  of  the  software  effort. 

One  of  the  most  significant  problems  facing  the  development  of  any 
tactical  data  system  has  been  changing  requirements.  TACFIRE  has  been 
no  exception.  Even  though  the  concept  formulation  phase  had  produced 
a "matured"  QMR  statement,  the  data  base  of  weapons  and  ammunition 
types  which  TACFIRE  was  to  accommodate  was  continually  shifting. 

Even  with  occasional  freezes,  the  time  would  always  come  when  TACFIRE 
had  to  catch  up.  Fortunately,  this  has  not  been  a major  problem  for 
TACFIRE.  More  pertinent  to  the  initial  delays  in  RDAT  was  an  increase 
in  requirements  for  the  Battalion  system,  partly  due  to  initial  under- 
estimation of  memory  requirements.  This  necessitated  an  early  (summer 
of  1968)  change  in  the  Battalion  system  to  include  the  addition  of 
random  access  drum  memory  units  (RAM).  This  was  a dramatic  change  for 
the  system,  with  major  software  implications  as  well  as  cost.  (With 
the  TPP  concept,  the  total  procurement  costs  for  over  100  drums  had  to 
be  considered  up  front). 
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Problems  with  the  Digital  Data  Terminal  (DDT)  caused  further  delay. 
Litton  was  subsequently  directed  to  drop  the  subcontract  effort  on  the 
DDT  by  RCA  and  build  it  in-house.  A delay  in  availability  of  RAM  drum 
units  also  had  a negative  impact. 

Many  of  the  ills  of  concurrent  hardware,  programming  support 
software  and  applications  software  development  contributed  to  the 
delays.  Real  time  operating  system  software  for  instance,  must  be 
intimately  structured  to  complement  the  physical  hardware.  Original 
software  development  had  to  be  done  using  a commercial  IBM  system  as 
host  machine  until  real  tactical  hardware  became  available.  Compila- 
tions and  assemblies  were  done  on  this  system  and  the  only  software 
testing  that  could  be  accomplished  was  done  using  a software  inter- 
preter to  simulate  the  tactical  hardware.  Transition  from  the 
programming  support  system  A (PSSA  on  IBM  hardware)  to  programming 
support  system  B (PSSB  on  Litton  hardware)  did  not  go  according  to 
plan. 

More  than  anything  else,  however,  the  serious  slippages  of  the 
TACFIRE  program  through  the  completion  of  the  RDAT  phase  must  be 
charged  as  management  failures  on  both  the  part  of  Litton  and  the 
Army.  These  same  failures  were  also  to  be  responsible  for  additional 
slippages  that  would  occur  later  as  a result  of  problems  that  would 
show  up  during  ET/EST. 

TACFIRE  development  was  planned  to  be  monitored,  as  mentioned 
earlier,  by  a series  of  reviews,  first  Preliminary  Design  Reviews 
( PDRs ) and  then  Critical  Design  Reviews  (CDRs).  The  design  of  the 
system  was  to  be  guided  by  Part  I specifications  (design  to),  to  be 
followed  later  with  Part  II  specifications  (build  to)  which  would 
reflect  the  final  design.  Testing  would  begin  with  Preliminary 
Qualification  Tests  (PQTs)  for  groupings  of  computer  program  modules, 
and  move  on  to  Formal  Qualification  Tests  (FQTs)  of  complete  software 
packages.  All  of  this  was  tied  together  in  a Configuration  Management 
Plan  which  called  for  a Software  Review  Board  (SRR)  to  carefully 
control  the  progress  of  the  system  and  changes  made  thereto.  This 
management  approach  could  have  been  quite  successful  if  followed 
through,  but  it  fell  apart  completely  in  implementation. 

The  original  Litton  software  effort  including  subcontracts  was 
scoped  at  about  $15  million.  Management  quickly  cut  this  to  $7  million 
and  then  in  the  competitive  crunch  included- only  $3.5M  in  their  final 
bid  price.  This  ensured  that  inadequate  resources  would  be  available 
for  software  and  doomed  the  software  management  approach  to  failure. 

The  Configuration  Management  Plan  was  never  really  implemented,  the 
SRB  never  constituted,  and  sufficient  software  personnel  were  not 
available,  especially  in  the  contractor  program  management  office. 

While  it  originally  appeared  that  the  two  experienced  software 
subcontractors  (PRC  and  Informatics)  would  be  substantially  involved 
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in  the  development  of  the  software,  in  fact  their  involvement  was 
minimal  with  the  bulk  of  the  critical  work  reverting  to  the  relativ- 
ly  inexperienced  Litton  group. 

For  its  part  the  Army  management  team  was  no  better  in  its  implemen- 
tation efforts.  The  PM  staff  was  equally  lacking  in  software  experience 
and  depth.  Tests  by  the  contractor  were  inadequately  monitored  and  the 
results  of  both  tests  and  design  reviews  were  not  well  documented.  In- 
sufficient effort  went  into  reviewing  test  plans  as  well.  Consequently, 
problems  in  PQT's  often  went  undetected  and  filtered  on  through  into  FQT's. 
In  short,  any  semblance  of  real  control  was  completely  lacking.  The 
problem  was  compounded  by  lack  of  continuity  on  the  part  of  the  Govern- 
ment personnel  from  one  review  or  one  test  to  the  next . 

Management  appreciation  for  the  crisis  in  software  was  lacking  in 
part  due  to  the  absence  of  measurable  milestones  visible  to  the  govern- 
ment between  June  1968  and  January  1970.  When  the  first  series  of  FQT 
planning  meetings  began  in  May  1970  the  problem  finally  began  to  come 
into  focus.  By  the  end  of  the  year,  the  PM  was  ready  to  acknowledge 
the  slippage  and  Mod  #50  to  the  contract  on  29  December  1970  formally 
rescheduled  the  start  of  ET/EST  for  May  1971  (from  the  original  Oct  69 
date)  and  stretched  the  TPP  contract  out  a total  of  30  months. 

Pressures  were  now  applied  to  Litton  to  tighten  its  management  controls 
and  apply  resources  to  implementing  its  software  management  plan. 

It  was  also  during  the  RDAT  period  that  yet  another  change  in 
project  management  structure  occurred.  Beginning  in  late  1970  and  on 
into  1971,  the  Army  established  the  Office  of  the  Project  Manager  for 
Army  Tactical  Data  Systems  (PM,  ARTADS)  within  the  Electronics  Command 
at  Fort  Monmouth,  NJ.  PM  responsibilities  for  TACFIRE  and  T0S  were 
shifted  from  the  Computer  Systems  Command  at  Fort  Belvoir  to  this  new 
PM  office.  At  the  same  time,  responsibility  for  monitoring  the  develop- 
ment of  the  software  for  these  systems  remained  with  CSC.  The  new  PM, 
ARTADS  thus  found  himself  with  PM  responsibility  for  TACFIRE,  but  the 
software  management  resources  he  needed  did  not  belong  to  him;  in  fact 
CSC  as  a major  Army  command  was  not  even  under  the  control  of  the  Army 
Materiel  Command  (AMC).  In  theory  any  major  disagreement  between 
PM,  ARTADS  and  CG,  CSC  over  TACFIRE  software  management  would  have  to 
be  resolved  at  the  Vice  Chief  (or  Asst  Vice  Chief)  of  Staff  level.  The 
lack  of  collocation  of  the  organizations  exacerbated  the  situation. 

Formal  Qualification  Tests  actually  got  underway  in  the  first 
quarter  of  FY  72  (mid-1971),  further  delaying  the  start  of  ET/EST.  This 
was  the  first  time  the  Government  had  overseen  the  actual  performance  of 
software.  Not  unexpectedly,  numerous  Operational  Deficiencies  (ODs) 
were  encountered,  the  most  serious  of  which  were  in  the  applications 
software.  ODs  were  separated  into  those  which  re  }u:ired  fixing  early, 
those  which  could  be  waived,  and  those  requiring  a formal  Engineering 
Change  Proposal  (ECP  to  bring  the  system  and  the  specifications 
into  agreement.  Reruns  of  the  FQTS  continued  into  early  1972 
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to  clear  the  outstanding  ODs.  A test  plan  was  also  developed  to  allow 
demonstration  of  the  total  integrated  TACFIRE  system  (hardware,  soft- 
ware and  communications)  as  the  culmination  of  RDAT. 

Early  indications  of  system  reliability  problems  were  also 
beginning  to  appear.  The  target  for  Mean  Time  Between  Failures  (MTBF) 
was  set  at  150  hours,  with  a Mean  Time  to  Repair  (MTTR)  of  30  minutes, 
as  per  the  QMR  and  system  specifications.  The  electromechanical 
equipment  in  TACFIRE  provided  the  most  problems.  Of  course,  it  was 
expected  that  initial  performance  would  fall  short  of  these  objectives 
and  that  reliability  would  improve  as  time  went  on. 

Once  again  the  contract  had  to  be  adjusted  to  catch  up  with  reality. 
On  6 Jan  1972  Mod  #60  was  signed  calling  for  ET/EST  to  start  in  March 
1972  with  the  first  production  release  scheduled  for  April  1973.  An 
additional  12  months  was  added  to  the  Mod  50  schedule,  bringing  the 
total  extension  to  39  months  between  the  beginning  of  ET/EST  and  the 
issuance  of  a production  go-ahead. 

After  reviewing  the  status  of  hardware  and  software  testing  as 
well  as  the  availability  of  trained  military  personnel,  the  PM  set 
1 April  1972  as  a realistic  target  date  for  the  beginning  of  ET/EST. 
Negotiations  on  a system  delivery  date  had  been  difficult  and  at  one 
point  (Sep  1971),  the  Government  had  unilaterally  instructed  the 
contractor  to  deliver  on  the  1st  of  April  1972.  The  contractor 
finally  agreed  in  Mod  60  to  this  date  as  a delivery  date  for  the 
ET/EST  systems  which  would  include  a DivArty  set,  three  direct  support 
artillery  battalion  sets,  one  general  support  Bn  set,  and  a missile 
battalion  set. 

The  total  integrated  system  test  began  in  February  and  continued 
through  late  March  of  1972.  PM  personnel  supervised  a "military 
operational  test"  of  the  ET/EST  systems  in  the  Litton  plant  on  29  March 
1972.  The  successful  completion  of  that  test  resulted  in  the  prelimin- 
ary acceptance  of  the  TACFIRE  system  for  ET/EST. 

The  PM  now  reassessed  the  total  situation  prior  to  making  a 
decision  as  to  whether  or  not  the  system  was  truly  ready  for  ET/EST. 

On  the  software  side,  while  there  were  still  problems  remaining,  the 
major  ones  identified  during  the  FQT  series  had  been  cleared  and  it 
appeared  that  reasonable  performance  could  be  anticipated.  Hardware 
problems  had  similarly  been  reduced  to  manageable  proportions  and  the 
known  limitations  would  be  acceptable.  Spare  parts  were  not  completely 
up  to  the  planned  levels,  but  the  maintenance  concept  had  generally 
proven  sound  and  a maintainability  demonstration  had  been  successfully 
completed.  After  coordinating  with  the  tester  (TECOM)  and  user  (CDC), 
the  PM  deemed  the  total  risk  situation  to  be  acceptable  and  decided 
to  proceed  into  ET/EST. 


An  interesting  side  issue  developed  with  the  contractor  over 
whether  or  not  the  "development"  phase  of  the  contract  had  now  been 
completed.  This  status  affected  certain  contractor  support  activities 
and  reporting  requirements.  Litton  maintained  that  development 
terminated  on  Army  acceptance  of  the  ET/EST  systems,  while  the  Army's 
position  was  that  development  continued  until  a production  go-ahead 
was  given.  This  issue,  somewhat  unique  due  to  the  TPP  contract, 
remained  in  contention  for  many  months.  In  the  meantime,  the  Array 
dictated  procedures  to  be  followed  for  the  control  and  maintenance 
of  software  during  the  ET/EST  phase. 

Engineering  Tests/Expanded  Service  Tests  (ET/EST) 


TACFIRE  was  now  entering  what  was  to  be  perhaps  its  most  inter- 
esting phase  from  the  point  of  view  of  a weapons  system  acquisition 
history.  ET/EST  was  to  begin  in  April  1972  and  run  into  February 
1973-  Unanticipated  problems  were  to  arise,  however,  with  unique 
and  interesting  management  solutions  ensuing  in  response  to  those 
problems . 

By  6 April  72,  two  battalion  systems  and  a DivArty  system  had  been 
delivered  to  the  White  Sands  Missile  Range,  New  Mexico,  a battalion 
system  had  arrived  at  Ft  Huachuca,  Arizona,  and  another  battalion 
system  was  in  place  at  Ft  Sill,  Oklahoma.  The  set  at  Ft  huachuca  was 
to  undergo  electromagnetic  compatibility  and  vulnerability  tests  as 
part  of  the  Engineering  Test  (ET),  and  on  completion  be  shipped  to 
Ft  Sill.  Similarly,  the  White  Sands  set  would  also  go  to  Ft  Sill  on 
completion  of  ET  to  augment  the  operational  test  facilities. 

Expanded  Service  Tests  (EST)  got  underway  at  Ft  Sill  on  8 April. 

The  Field  Artillery  Board  began  exercising  the  system  to  determine 
its  operational  suitability.  Software  and  hardware  problems  began 
showing  up  almost  from  the  start.  Also,  shortcomings  in  the  draft 
technical  manuals  seriously  compounded  the  operational  problems. 

The  situation  was  so  bad  that  tests  were  suspended  for  more  than  a month 
beginning  on  27  April,  to  permit  the  contractor  to  perform  necessary 
maintenance . 

At  White  Sands,  the  ET  system  ran  into  similar  problems  - again 
both  hardware  and  software  deficiencies.  Here,  too,  the  decision  was 
made  to  suspend  testing  as  of  1 May  to  give  the  contractor  a chance 
to  solve  at  least  the  most  critical  problems. 

In  the  hardware  area,  mechanical  problems  were  plaguing  the  fixed 
format  message  entry  devices  (FFMEDs),  the  plotter  maps,  the  keyboards 
and  the  printers.  Power  supply  problems  were  also  responsible  for  an 
alarming  number  of  system  failures,  along  with  cables.  Finally,  RAM 
memory  capacity  for  the  battalion  system  showed  signs  of  strain. 

Software  problems  were  the  most  serious,  however.  Under  some 
conditions  the  system  would  issue  erroneous  fire  commands  or  none  at 
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all.  Fire  planning  procedures  frequently  produced  2‘esults  wherein 
targets  were  omitted,  fires  exceeded,  or  available  fire  units  over- 
looked. Some  of  the  fire  support  element  programs  were  virtually 
unusable.  Ballistic  solutions  for  very  short  ranges  or  high  angles 
were  ■■'enerally  inaccurate. 

Early  in  June,  following  an  intensive  period  cf  hardware  mainten- 
ance and  re-engineering,  as  well  as  extensive  software  changes, 
testing  was  resumed.  Problems  continued  to  show  up  and  it  soon 
became  apparent  that  the  entire  test  plan  could  not  be  successfully 
implemented.  A high  level  management  review  was  in  order. 

On  19  July  1972,  the  Pit  convened  a senior  level  management 
meeting  to  review  the  situation.  General  officers  from  TECOM,  the 
Field  Artillery  School,  Computer  Systems  Command,  and  Combat  Develop- 
ments Command  participated,  in  addition  to  PM,  AF.TAD3.  A+  issue 
was  whether  testing  should  be  continued  or  terminated,  with  the 
latter  co\rrse  of  action  carrying  serious  implications  about  the 
future  of  the  TACFIRE  project.  On  the  positive  ride,  mobility  testing 
and  environmental  testing  had  gone  well  and  them ■ was  something  to  be 
gained  by  continuing  at  least  some  portions  of  the  testing.  Out  of 
this  meeting  came  a decision  to  continue  with  limited  testing  inio 
September,  at  which  time  a new  software  tape  would  be  made  available 
by  the  contractor  and  full  ET/EST  could  resume. 

Additional  corrective  measures  were  also  directed  as  a result, 
of  this  meeting  including  an  accelera+ed  delivery  of  the  system  from 
"JSMR  to  Ft  Sill,  establishment  of  an  Equipment  Performance  Report  (EPF.) 
review  task  force,  accelerated  interim  software  corrections  with  a 
schedule  of  5 intermediate  revised  tapes,  and  creation  of  a user 
guidance  group. 

Serious  problems  continued  to  arise.  In  August.,  it.  became  evident 
that  it  would  be  impossible  to  complete  sufficient  testing  to  enable 
a production  decision  to  be  made  by  the  required  date  of  1 April  1973- 
The  Department  of  the  Army  (DA)  was  now  brought  in  and  a series  of 
briefings  and  reviews  was  begun.  Meanwhile,  formal  testing  continued 
on  an  intermittent  basis  only. 

Following  meetings  in  the  Pentagon  on  August  10th  and  14t.h,  DA 
endorsed  most  of  the  actions  already  taken  by  t.he  PM.  The  most 
significant  outcome  of  these  meetings  was  a formalization  and  strength- 
ening of  the  user  guidance  role  that  had  recently  been  initiated.  On 
17  August,  DA  sent  out  a message  formally  designating  the  Field 
Artillery  Center  as  the  "using  agency  for  TACFIRE"  with  a number  of 
specific  responsibilities.  Most  important,  t.he  designated  user  was 
charged  with  the  task  of  reviewing  each  EPR  as  written  by  TECOM,  to 
"determine  from  the  user  standpoint  the  minimum  acceptable  level  of 
performance  required  in  each  deficient  area..."  Further,  the  user 
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would  ’establish  for  PM,  ARTADS  the  relative  priority  from  the  user 
viewpoint  for  correcting  deficiencies  and  shortcomings  identified  in 
EPR's."  User  determinations  were  to  be  promulgated  by  message  to  all 
concerned. 

The  significance  of  the  designated  user  cannot  be  overemphasized. 
Here  for  the  first  time  was  a single  focal  point  within  the  Army 
empowered  to  speak  with  virtually  final  authority  on  modifications  to 
the  TACFIRE  requirement  pertaining  to  the  pure  field  artillery 
function.  Items  that  impacted  beyond  the  field  artillery  domain  had 
to  be  coordinated  with  CDC  before  a user  determination  item  could  be 
published,  but  these  were  a small  percentage. 

Heretofore,  the  tester  had  little  choice  but  to  cite  a deficiency 
each  time  the  system  failed  to  measure  up  to  the  letter  of  the  QMR, 
now  over  6 years  old.  This  new  procedure  allowed  the  designated  user 
to  ask  not  "does  the  system  do  what  the  QMR  says  it  must,"  but 
instead  "is  the  performance  of  the  system  adequate  to  fulfill  the 
needs  of  the  field  artillery?"  If  the  answer  to  the  latter  question 
was  yes,  then  the  "User  Determination  Item"  so  stating  it  became  a 
de  facto  modification  of  the  requirement.  Each  EPR  was  to  be  analyzed, 
a determination  made  and  a rationale  given  for  the  determination, 
all  to  become  part  of  the  permanent  record.  (Representative  User 
Determination  Item  messages  are  included  in  Appendix  B). 

One  of  the  major  benefits  achieved  by  this  system  was  that  it 
forced  a renewed  challenge  of  the  TACFIRE  requirements.  If  a require- 
ment did  not  stand  up  to  careful  scrutiny,  a simple  mechanism  was 
now  available  to  modify  the  requirement  accordingly.  Equally  important 
was  the  psychological  factor.  No  longer  was  TACFIRE  simply  a system 
being  developed  by  the  materiel  developer  to  meet  the  wish  list  of 
a remote  and  intangible  "user . " The  user,  now  well  identified,  became 
a true  system  proponent  and  in  effect  a part  of  the  development  team. 
The  independent  tester  role,  however,  remained  separate  to  provide 
for  necessary  checks  and  balances. 

Not  only  had  the  production  decision  date  of  April  1973  become 
totally  impractical,  but  the  production  quantities  planned  when  the 
TPP  contract  was  signed  in  1967  no  longer  reflected  the  needs  of  the 
Army  in  view  of  changes  to  the  force  structure.  Faced  with  continued 
technical  problems  and  obvious  contractual  inadequacies,  the  PM  set 
in  motion  a process  aimed  at  reaffirming  the  Army's  needs  for  TACFIRE 
and  making  the  necessary  reorientations  to  the  overall  TACFIRE  program. 

Several  alternative  courses  of  action  were  presented  to  DA  by  the 
PM  in  October  1972.  These  ranged  from  continuing  the  program  unchanged 
to  termination,  with  a middle  ground  of  restructured  alternatives. 

Among  the  latter  were  an  alternative  stretching  out  and  repricing 
full  scale  production,  two  alternatives  calling  for  completion  of 
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development  with  either  no  production  or  a procurement  package  aimed 
at  a separate  competition  for  production,  and  an  alternative  providing 
for  a Low  Rate  Initial  Production  (LRIP)  only,  with  options  for  full 
scale  production. 

Termination  was  still  a very  real  alternative  at  this  time.  It 
could  not  be  discounted  without  a review  of  the  Army's  true  requirement 
for  TACFIRE.  To  address  this,  DA  established  in  late  October  a "Senior 
TACFIRE  User  Validation  Committee"  (TACVAL)  consisting  of  general  officers 
and  chaired  by  the  CG,  1st  Infantry  Division.  The  TACVAL  committee  met 
at  Ft  Sill,  OK  from  2 through  6 November,  and  on  15  November  their 
recommendations  were  presented  to  a special  ASARC.  They  had  reaffirmed 
the  need  for  TACFIRE  and  recommended  continued  development  on  an  extended 
schedule. 

The  special  ASARC  accepted  the  recommendations  of  the  TACVAL  committee 
and  convened  a second  committee  (TACVAL  II),  chaired  by  PM,  ARTADS  to 
evaluate  four  alternative  courses  of  action  developed  by  DA.  This 
committee  presented  its  findings  to  a second  special  ASARC  on  27  November 
1972. 

The  course  of  action  recommended  and  approved  by  the  special  ASARC 
contained  three  major  elements.  First,  it  called  for  completion  of 
the  development  of  TACFIRE,  ruling  out  termination  at  this  time.  Second, 
it  directed  new  scheduling  to  allow  correction  of  system  deficiencies 
and  retesting,  plus  changes  to  the  procurement  quantity.  This  would 
require  a modification  to  the  contract.  Finally,  the  ASARC  directed 
that  the  project  be  brought  into  line  with  the  new  acquisition  policies 
which  had  been  published  by  the  Army  in  AR  1000-1  on  30  June  72. 

One  of  the  most  significant  aspects  of  the  new  AR  1000-1  was  a 
revised  testing  structure.  Testing  was  now  divided  into  two  broad 
categories  of  Development  Testing  (DT)  and  Operational  Testing  (0T). 

DT  focuses  on  determining  how  well  the  system  satisfies  the  detailed 
criteria  set  forth  in  the  requirements  documents  and  is  conducted  by 
TEC0M  as  an  independent  development  tester  (within  AMC).  The  purpose 
of  0T  is  to  answer  the  question:  "Can  a unit  equipped  with  the  new 
system  accomplish  its  mission  in  a tactical  environment?"  The  US  Army 
Operational  Test  and  Evaluation  Agency  (0TEA)  was  created  as  an  agency 
separate  and  distinct  from  the  developing/procuring  command  to  be 
responsible  for  0T.  Three  series  of  tests,.  DT/0T  I,  II,  III  would  be 
conducted  through  the  development  cycle. 

The  next  set  of  formal  tests  that  TACFIRE  was  to  undergo  would  now 
be  restructured  into  a DT/0T  II  series.  The  PM  recognized  that  extensive 
hardware  and  software  modifications  and  corrections  would  be  required 
before  the  system  would  be  ready  for  these  tests.  During  the  stretched 
out  development  time  now  planned,  it  would  be  necessary  to  use  the 
prototype  systems  for  an  intensive  and  continuous  cycle  of  problem 
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identification,  correction  and  informal  testing.  This  was  to  become 
known  as  the  "Find,  Fix,  and  Test"  period  of  the  development  of  TACFIRE. 

A final  hurdle  remained  before  the  recommended  restructuring  of 
the  TACFIRE  program  could  be  implemented.  Department  of  Defense  approval 
was  sought  in  a briefing  presented  to  a special  DSARC  on  11  January  1973. 
The  DOD  group  directed  that  the  alternatives  considered  be  further 
developed  and  presented  formally  in  a revised  Development  Concept  Paper 
(DCP)  for  decision.  Accordingly,  PM  ARTADS  submitted  a revised  DCP  with 
a recommended  course  of  action  consistent  with  the  approach  that  had 
previously  been  approved  by  the  special  ASARCs. 

The  revised  DCP  was  approved  by  the  Deputy  Secretary  of  Defense  on 

30  March  1973.  The  PM  now  had  authority  to  renegotiate  the  contract  to 

increase  development  time  and,  significantly , alter  the  type  of  contract 
from  the  controversial  TPP  to  a Cost  Plus  Fixed  Fee  (CPFF)  type  for 
development,  with  options  for  subsequent  production.  This  would  give 
the  Government  the  flexibility  of  not  going  ahead  with  production  if 
the  outcome  of  development  testing  was  unsatisfactory.  ^ 

In  his  approval  of  the  DCP  recommendation,  the  Deputy  Secretary  of 
Defense  added  a requirement  that  the  Army  develop  a plan  that  would 
permit  subsequent  competition  for  production  on  completion  of  the  test 
and  evaluation  phase  of  TACFIRE.  Considering  the  complexity  of  the 
program  and  the  previous  production  commitment  under  the  TPP  concept, 
a plan  to  inject  meaningful  competition  into  the  program  at  a future 
date  would  require  careful  thought  and  prove  to  be  a challenging  effort. 

Negotiations  with  Litton  had  been  going  on  in  anticipation  of  the 
DCP  approval,  enabling  Mod  88  to  the  contract  to  be  signed  effective 

31  March  1973.  The  contract  was  converted  to  a CPFF  type  development 
contract  as  desired.  The  production  commitment  was  deleted  in  favor 
of  an  option  for  Low  Rate  Initial  Production  (LRIP)  and  an  option  for 
full  scale  production,  both  with  ceiling  costs  negotiable  downward. 

An  option  for  a competitive  procurement  data  package  was  also  included 
with  the  price  to  be  negotiated.  The  development  phase  was  extended 
by  eighteen  months  to  correct  deficiencies  (at  the  contractor's  expense) 
and  also  to  add  capabilities  identified  by  the  user  as  essential. 

The  Government  also  achieved  a reduction  in  the  termination  costs  (by  1/3) 
in  the  event  of  cancellation.  In  trade  for  these  considerations,  the 
development  costs  were  increased  considerably  (about  15$),  but  the  new 
figure  was  a ceiling  above  which  the  contractor  would  absorb  all  costs. 

The  new  schedule  now  placed  the  production  decision  in  the  December 
1974  time  frame,  after  a six  month  DT/OT  II  (April  through  October)  and 
a suitable  evaluation  period.  Assuming  a successful  DT/OT  and  ASARC/ 

DSARC  approval,  the  PM  planned  to  recommend  LRIP  be  initiated  in  December, 
followed  by  a DT/OT  III  in  January  1976,  with  the  possibility  of  full 
scale  production  beginning  in  February  1977.  Total  slippage  in  the 
program  since  the  original  contract  was  signed  was  now  up  to  65  months. 
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The  signing  of  Mod  88  climaxed  perhaps  the  most  trying  stage  of 
the  TACFIRE  program.  The  many  software  and  hardware  problems  had  not 
all  been  solved  by  any  means,  but  the  restructuring  of  the  overall 
program  brought  with  it  a reasonably  sound  approach  to  the  continuation 
of  the  development  phase,  with  some  hope  for  success. 

Find,  Fix  and  Test 


During  the  first  twelve  months  of  the  post-Mod  88  period,  the  pro- 
gram was  to  shift  into  the  Find,  Fix,  Test  mode  briefly  described 
earlier.  Architected  by  the  Project  Manager  as  an  innovative  develop- 
ment approach,  this  mode  of  operation  was  unique  in  several  ways.  As 
a modified  form  of  customer  test,  the  contractor  had  control  of  the 
systems  approximately  three  fourths  of  the  time  to  develop  and  test 
solutions  to  the  deficiencies  that  had  arisen  during  ET/EST.  The 
remaining  quarter  of  the  time  the  Government  had  control  of  the  system 
to  validate  the  contractor's  corrections  and  attempt  to  discover  other 
areas  where  correction  might  be  required.  Time  was  shared  on  a daily 
basis  for  these  purposes.  A detailed  memorandum  of  agreement  (Appen- 
dix C)  between  Litton  and  the  PM  spelled  out  the  procedures  and 
schedule  to  be  followed. 

In  the  traditional  system  development,  the  contractor  controls  the 
equipment  for  an  extended  period  of  time  (months  or  years)  to  develop 
the  system.  Then  the  system  is  turned  over  to  the  Government  for  an 
intensive  and  lengthy  series  of  formal  tests  by  the  testing  organization 
At  the  conclusion  of  these  tests,  the  system  together  with  a list  of 
deficiencies  is  returned  to  the  contractor  for  correction. 

With  a system  as  complex  as  TACFIRE,  this  may  well  be  an  inherently 
unstable  development- testing  cycle.  Correcting  hundreds  of  deficiencies 
at  a time,  with  no  intermediate  feedback  from  the  user  may  result  in 
the  introduction  of  an  equal  number  of  new  deficiencies.  Find,  Fix  and 
Test  sought  to  collapse  that  cycle  into  much  shorter  intervals,  handling 
fewer  problems  at  a time,  and  with  the  aid  of  the  user  and  tester,  pro- 
viding early  feedback  to  the  contractor  as  to  the  adequacy  of  his  fixes. 

We  have  already  cited  the  critical  supporting  role  now  being  played 
by  the  designated  user.  Find,  Fix  and  Test  brought  with  it  the  equally 
critical  supporting  role  to  be  played  by  the  tester  (TECOM).  Resources 
of  the  testing  community  were  employed  to  aid  the  developer  in  problem 
identification  and  correction  validation,  thus  further  expanding  the 
development  team.  Formal  testing  would  later  be  conducted  in  the 
traditional  manner  ( DT/OT  II)  to  ensure  that  the  testing  process  had 
not  been  compromised.  It  may  be  that  a form  of  Find,  Fix,  and  Test  is 
essential  in  any  computer  system  development  project  comparable  to 
TACFIRE  in  complexity. 

Solid  progress  was  made  throughout  the  ensuing  year  of  Find,  Fix 
and  Test.  In  January  of  1974,  the  PM  began  an  assessment  of  system 


status  to  determine  whether  or  not  DT/OT  II  could  begin  on  1 April  as 
planned.  The  general  conclusion  was  that  the  majority  of  the  problems 
had  been  corrected,  but  others  remained  as  outstanding  deficiencies. 

In  coordination  with  the  designated  user,  all  problem  reports  not 
yet  cleared  up  were  reviewed  to  obtain  agreement  as  to  those  which 
required  correction  prior  to  the  start  of  DT/OT  II,  those  that  could 
be  corrected  during  the  DT/OT  II  period,  and  those  of  lowest  priority 
which  could  be  postponed  until  the  subsequent  production  phase. 

The  PM  had  been  pursuing  a strategy  of  parallel  developments  and 
product  improvements  to  solve  the  more  critical  hardware  problems  in 
an  all  out  effort  to  improve  system  reliability.  This  allowed  for 
continued  usage  and  minor  upgrades  of  existing  items  of  equipment 
until  such  time  as  a major  improvement  could  be  made  by  insertion  of 
a product  improved  item  or  a totally  new  replacement  item.  A number 
of  TACFIRE  equipments  were  being  upgraded  in  this  manner,  including 
the  FFMED,  the  electronic  line  printer,  and  most  recently  the  RAM 
drums.  In  the  case  of  the  RAM,  a priority  effort  was  underway  to 
permit  eventual  replacement  of  the  drums  with  all  electronic  Mass  Core 
Memory  Units  (MCMUs)  which  would  significantly  alter  the  system  perfor- 
mance and  memory  capacity.  M ajor  software  changes  would  also  be  re- 
quired to  accommodate  and  take  full  advantage  of  the  MCMUs.  The 
parallel  development  approach  minimized  technical  risk,  while  providing 
considerable  flexibility  to  the  project  manager.  Where  different 
vendors  were  involved  for  the  old  and  new  ixems,  an  obvious  competitive 
advantage  was  also  realized. 

Other  hardware  problems  such  as  those  associated  with  the  power 
supplies  were  yielding  to  intensive  engineering  programs  aimed  at  making 
the  existing  equipment  perform  in  accordance  with  design  criteria.  Here, 
too,  reliability  was  inching  upward. 

Each  of  the  revised  software  tapes  had  brought  with  it  considerable 
improvement  over  its  predecessor  with  numerous  software  deficiencies 
being  corrected.  A final  DT/OT  II  version  was  scheduled  for  March  1974. 
It  would  include  provisions  for  testing  the  MCMU  which  had  already 
successfully  passed  basic  qualification  tests  the  preceeding  August. 

At  the  end  of  January  1974,  the  PM  reported  to  the  Commanding 
General  of  AMC  that  he  felt  that  DT/OT  II  could  commence  on  1 April. 

His  plan  called  for  Litton  to  turn  the  system  back  to  the  Government 
at  the  end  of  February,  with  the  month  of  March  being  used  to  wrap  up 
final  preparations  for  the  test  series.  An  updated  form  DD250  would 
document  the  specific  known  deficiencies  in  the  system  that  Litton 
would  subsequently  be  required  to  correct,  but  which  would  not  prohibit 
DT/OT  II  from  beginning. 


As  it  turned  out,  DT/OT  II  did  not  officially  begin  until  14  May 
74.  The  reason  for  this  delay  was  not  technical  problems,  but  another 
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contractual  disagreement  between  the  government  and  Litton.  Litton  had 
announced  that  their  understanding  of  the  language  of  Mod  86  was  that 
signing  the  DD250s  constituted  final  acceptance  of  TACFIRE  except  for 
deficiencies  specifically  cited.  The  Government  maintained  that  final 
acceptance  could  not  occur  until  after  DT/OT  II  was  completed  and  all 
non-compliances  with  contractual  specifications  could  be  determined. 

This  would  keep  the  club  of  default  over  the  contractor's  head  on  into 
the  DT/OT  III  test  series  preceding  production. 

The  DD250  situation  remained  a standoff.  Both  parties  wanted  to 
get  on  with  the  testing  to  keep  the  program  moving.  Since  the  dispute 
centered  on  what  the  meaning  of  newly  signed  DD250s  was  to  be  contract- 
ually, the  problem  was  effectively  sidestepped  by  the  simple  expedient 
of  not  signing  a new  set  of  DD250s.  This  amounted  to  a de  facto  victory 
for  the  Government  since  Litton  was  not  relieved  of  any  responsibility 
for  system  deficiencies,  but  at  the  same  time  it  left  the  door  open 
for  Litton  to  make  a subsequent  case  if  they  so  desired.  A separate 
agreement  was  executed  to  establish  support  responsibilities  of  the 
contractor  and  liability  responsibilities  of  the  Government  for  the 
equipment  during  the  test  period. 

The  OT  II  operational  test  was  conducted  by  OTEA  during  the  period 
8-26  July  1974  with  generally  successful  results.  One  of  the  primary 
operational  objectives  was  to  demonstrate  improved  system  reliability. 

As  intermediate  goals  on  the  way  to  achieving  the  specification  require- 
ment of  150  hours  MTBF,  30  hours  MTBF  had  been  the  target  to  permit 
entry  into  DT/OT  II  and  90  hours  required  at  the  conclusion.  The 
actual  values  were  nearly  50  hours  MTBF  when  the  tests  began,  rising 
to  123  hours  at  the  conclusion  of  DT/OT  II.  (It  should  be  noted  that 
reliability  values  change  in  one  of  two  ways:  on. the  one  hand  the 
performance  of  the  system  changes,  while  on  the  other  hand  the  "charge- 
able" failures  may  change  as  a result  of  a scoring  conference.  Both 
of  these  factors  were  present  and  contributed  to  the  dramatic  relia- 
bility growth.  ) 

By  the  end  of  September,  the  bulk  of  DT/OT  II  had  been  completed. 
TECOM  wound  up  the  DT  phase  and  the  test  series  terminated  officially 
on  8 November.  The  PM,  the  user  and  test  communities  now  began 
massaging  the  test  results  and  preparing  for  the  upcoming  ASARC  and 
DSARC  presentations. 

In  preparing  for  the  ASARC/DSARC  III  series,  Department  of  the 
Army  used  the  Red  Team  approach  to  shake  down  their  alternatives.  The 
alternatives  considered  were  (l)  terminate  the  program;  (2)  continue 
under  the  present  contract,  going  on  into  LRIP  and  then  Full  Scale 
Production  with  Litton;  and  (3)  exercising  the  LRIP  option  with  Litton, 
but  providing  the  basis  for  competition  in  FSP  by  acquiring  a technical 
data  package.  Two  variants  on  alternative  (3)  were  for:  (a)  full 
competition  for  FSP  based  on  the  LRIP  design:  and  (b)  comnetition  for  FSP 
based  on  product  improved  designs  of  selected  subsystems,  to  include  the 
oomnuter  svbsystem.  This  latter  alternative  ( 3t ) was  the  PM's  preferred 
alternative. 
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The  preferred  alternative  in  part  reflected  the  PM's  strategy  in 
response  to  the  earlier  OSD  guidance  to  show  how  competition  could  be 
brought  into  the  program.  Full  system  competition  did  not  appear  to 
be  practicable  for  a system  of  the  size  and  complexity  of  TACFIRE. 
Individual  subsystems  or  separately  identifiable  end  items  could 
probably  be  competed  effectively,  and  in  fact  this  was  a natural 
extension  of  the  parallel  development  of  product  improved  items  already 
being  accomplished. 

Initially  the  Red  Team  cri-fi'qued  the  PM's  alternatives,  and  subse- 
quently the  team  was  directed  to  assist  in  refinement  of  the  alternatives. 
During  the  actual  council  sessions,  the  Red  Team  made  an  independent 
presentation  of  its  areas  of  concern  over  the  preferred  alternative. 

These  included  the  additional  R&D  costs  to  be  funded,  the  practicability 
of  developing  and  using  technical  data  packages,  and  the  effects  of 
subsequent  design  changes  on  the  validity  of  previous  test  results. 

This  use  of  the  Red  Team  approach  seems  to  have  been  reasonably  con- 
structive, although  the  costs  (100K)  were  probably  excessive  for  the 
results  obtained. 

V.  LIMITED  PROCUREMENT 

TACFIRE  took  a major  step  forward  on  its  long  journey  to  the  field 
when  the  DSARC  III  and  Deputy  Secretary  of  Defense  approved  the  Limited 
Procurement  (LP)  of  14  additional  TACFIRE  sets  on  28  January  1975. 

This  decision  was  a modification  of  the  PM's  preferred  alternative. 

There  is  significance  in  the  fact  that  the  system  went  into  ''LP"  rather 
than  "LRIP."  LRIP  implies  that  a production  line  is  being  brought  up 
prior  to  commencement  of  Full  Scale  Production.  The  14  sets  would 
enable  an  extensive  DT/OT  III  test  series  to  be  performed  before  the 
FSP  commitment  was  made.  An  ASARC/DSARC  Ilia  was  planned  to  effect 
that  decision. 

Several  changes  to  the  system  were  also  directed  by  the  DSARC  III. 

One  of  the  most  significant  was  the  conversion  from  RAM  to  an  all  MCMU 
memory  system.  Another  was  the  substitution  of  a new  all  electronic 
Digital  Message  Device  (DMD)  for  the  electromechanical  FFMED  which  the 
user  had  found  unsatisfactory.  Other  changes  included  an  improved  line 
printer,  display  editor  and  keyboard.  The  impact  of  these  changes  was 
minimized  by  the  parallel  efforts  that  had  been  going  on  in  these  areas 
as  described  earlier,  and  consistent  with  the  PM's  preferred  alternative. 

With  OSD  approval  in  hand,  the  PM  was  able  to  exercise  the  option 
provided  by  Mod  88  for  14  additional  TACFIRE  sets.  The  contractor  had 
submitted  a detailed  proposal  for  both  LRIP  and  FSP  the  preceding  May 
and  negotiations  since  that  time  had  wonked  out  most  of  the  details. 

A supplemental  agreement  was  executed  on  30  January  1975  to  begin  this 
new  work. 

The  overall  TACFIRE  program  schedule  had  now  grown  by  another  36 
months,  bringing  the  total  to  101  months  beyond  the  unrealistic  date 
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programmed  when  the  original  contract  had  been  let  in  1967.  The  LP 
phase  with  a First  Article  Test  (FAT),  Force  Development  Test  and 
Evaluation  (FDTE),  DT/OT  III,  and  following  ASARC/DSARC  Ilia  added  ab  it 
15  months,  plus  an  additional  nine  months  to  incorporate  changes  to  the 
Communications  Control  Unit  ( CCU ) which  had  been  added  to  the  system 
earlier,  and  to  update  the  systems  data  base  to  service  all  required 
weapons.  Finally,  a 12  month  stretchout  in  the  Full  Scale  Production 
phase  was  anticipated.  These  would  all  be  reflected  in  Mod  130  to  the 
contract  as  of  June  1975. 

Software  Management  and  Incentives 


While  major  strides  had  been  taken  toward  developing  a fieldable 
set  of  TACFIRE  software,  serious  deficiencies  remained  in  many  areas. 
The  awkward  wording  relationship  between  the  two  commands  involved 
(CSC  with  software  responsibility  and  ECOM  with  hardware  and  system 
responsibilities)  has  already  been  mentioned  and  this  undoubtedly  had 
contributed  to  the  difficulties  of  managing  the  software  development 
efforts.  Reports  generated  at  the  CSC  working  level  were  subject  to 
sanitizing  and  softening  as  they  bubbled  up  through  the  organizational 
heirarchy.  The  PM's  knowledge  of  software  status  had  suffered  under 
this  arrangement. 

One  of  the  biggest  problems  under  the  split  management  arrangement 
was  the  dominance  of  administrative  data  processing  personnel  in  the 
Computer  Systems  Command.  There  are  major  differences  between  batch 
processed  financial,  personnel  and  logistical  data  processing  systems 
and  on-line  real-time  command  and  control  systems.  As  an  example  the 
operating  system  for  one  is  vastly  different  from  the  other.  In  this 
area  alone  ARTADS  experienced  great  difficulty  in  working  with  CSC 
personnel  unfamiliar  with  real-time  software.  Differences  in  programm- 
ing languages  and  hardware  structures  were  also  significant.  The 
problems  between  the  two  organizations  were  compounded  by  attempts 
within  CSC  to  impose  its  internal  documentation  standards  on  the  con- 
tractor. In  some  cases  the  PM  found  CSC  personnel  issuing  instructions 
which  amounted  to  constructive  changes  to  the  contract,  creating  an 
intolerable  situation  for  a project  manager. 

A hidden  blessing  in  the  stretched  out  TACFIRE  development  cycle 
was  realized  in  that  newly  assigned  personnel  frequently  had  previous 
TACFIRE  experience.  This  improved  the  corporate  memory  situation  and 
enhanced  the  experience  and  expertise  level's  as  well.  As  an  example, 
the  TACFIRE  director  in  the  ARTADS  organization  at  the  time  of 
transition  into  LP  had  been  involved  in  the  ea^ly  stages  of  the  program 
first  as  part  of  the  CDC  team  and  then  in  the  startup  of  the  ADFSC 
office . 

The  ARTADS  organization  also  benefited  from  the  assignment  in  1974 
of  an  officer  who  had  been  in  the  resident  development  office  with 
Litton  shortly  after  the  contract  was  awarded,  representing  the 


Artillery  School  and  assisting  in  software  monitoring.  He  came  to 
TACFIRE  fresh  from  graduate  school  having  acquired  a Master's  Degree 
in  computer  science.  For  the  first  time  the  PM  had  directly  available 
to  him  an  individual  with  both  the  experience  and  technical  background 
required  to  really  come  to  grips  with  the  software  management 
problem  and  this  became  his  assignment. 

With  his  own  software  manager  now  on  board,  the  PM  drew  up  a 
comprehensive  software  management  plan  addressing  within  the  structure 
of  the  existing  contract  (and  making  the  best  of  the  ECOM/CSC  split 
responsibilities)  how  software  would  be  managed,  the  milestones, 
documentation,  review  process  and  so  forth.  Key  to  the  overall 
management  concept  was  a new  incentive  program  for  software. 

Entering  into  the  LP  phase,  the  PM  made  available  $11.1  to  be  used 
for  incentives.  The  previous  incentives  in  the  program  had  actually 
turned  out  to  be  counter-productive  and  so  extreme  care  went  into 
considering  how  to  structure  incentives  properly  in  the  new  contractual 
phase.  Hardware  and  software  incentives  were  both  considered,  but  it 
quickly  became  apparent  that  the  greatest  program  leverage  could  be 
achieved  in  the  area  of  software.  In  retrospect  this  was  one  of  the 
best  decisions  made  in  the  TACFIRE  program. 

Earlier  lessons  learned  contributed  to  the  structuring  of  the  new 
incentive  package.  One  area  of  difficulty  is  in  measuring  the  per- 
formance of  the  contractor  to  determine  whether  or  not  the  incentives 
are  to  be  paid.  Generally  this  involves  the  establishment  of  a formal 
awards  board  which  must  make  subjective  judgments.  In  this  case  the 
need  for  a board  was  avoided  by  making  the  criteria  extremely  simple, 
thus  reducing  the  evaluation  process  to  an  equally  simple  yes/no 
determination. 

Both  lessons  learned  and  ASARC  guidance  militated  against  giving 
the  contractor  a large  number  of  varied  software  tasks  to  accomplish 
and  then  waiting  until  the  formal  qualification  test  period  to  deter- 
mine his  compliance.  Intermediate  goals  had  to  be  established  and 
used  as  management  targets  by  both  sides. 

With  these  constraints  in  mind,  the  Government  began  negotiating 
a software  incentive  package  with  the  contractor  in  early  1975.  A 
set  of  four  major  efforts  emerged,  separately  incentivized  and  to 
be  accomplished  serially.  This  would  permit  an  intensive  effort  to 
be  applied  to  each,  with  completion  of  one  effort  accomplished  before 
the  next  was  to  begin.  With  the  satisfactory  completion  of  one  of 
the  tasks,  the  contractor  would  receive  the  incentive  fee  for  that 
task,  representing  almost  all  profit  to  him  over  and  above  his  separate- 
ly funded  costs.  This  provided  the  contractor  with  an  extremely  power- 
ful incentive  to  comply  with  the  Government  desires. 
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The  first  major  task  called  for  completing  transitioning  to  the 
new  compiler.  The  deliverable  compiler  (one  hosted  on  the  TACFIRE 
computer)  was  at  that  time  not  yet  in  regular  use.  (The  first  version 
was  not  accepted  and  a second  version  was  written  by  another  subcontrac- 
tor), Software  was  still  being  generated  by  the  compiler  running  on  the 
IBM  360  system.  Litton’ s task  was  to  complete  the  new  compiler  and  to 
demonstrate  its  proper  functioning  by  taking  the  last  compiled  TACFIRE 
software,  compiling  it  on  the  new  system,  executing  the  total  system 
(operating  system,  applications  programs,  and  maintenance  and  diagnostics), 
and  comparing  the  results.  This  benchmark  was  satisfactorily  completed 
in  June  of  '75  and  Litton  received  the  full  $200K  incentive  allocated 
to  that  task. 

Next  in  the  serial  process  came  the  correction  of  outstanding  EPR's 
left  over  from  the  Find,  Fix  and  Test  mode.  After  careful  review,  the 
Government  and  the  contractor  agreed  on  100  EPRs  that  were  within  the 
scope  of  the  contract  and  still  required  correction.  An  incentive  fee 
of  $300K  was  attached  to  these  EPRs,  but  with  strings  to  ensure  that 
the  contractor  did  not  simply  fix  the  easiest  (which  constituted  the 
majority)  and  then  forfeit  the  remaining  fee  for  the  more  difficult 
EPR's.  The  fee  was  so  structured  that  fixing  8055  netted  payment  of 
a third  ($100K),  90%  netted  two  thirds,  and  100%  would  result  in  payment 
of  the  full  $300K  fee.  Working  with  the  CSC  team,  the  PM  further 
identified  42  of  the  100  EPRs  as  the  most  difficult.  To  qualify  for 
full  payment  of  any  of  the  fees,  the  criteria  required  that  the  applicable 
percentage  of  fixed  EPRs  had  to  include  the  same  percentage  of  the  42 
most  difficult.  The  final  result  spoke  well  for  both  Government  manage- 
ment and  contractor  performance  in  that  all  100  EPRs  were  verified  as 
corrected  and  the  full  $300K  was  paid. 

Following  completion  of  the  old  EPRs,  attention  now  turned  to  the 
operating  system.  The  existing  system  was  still  based  on  the  use  of 
the  RAM  drums  and  required  shifting  to  an  all-core  memory  system  with 
the  new  MCMUs.  Completion  of  this  task  could  be  determined  readily 
by  repeating  the  test  that  had  earlier  been  used  to  verify  the  EPRs. 

If  the  same  results  were  obtained  with  the  system  running  in  an  all-core 
environment,  it  could  be  inferred  that  the  OS  was  correct.  This  Litton 
did  satisfactorily  and  they  were  awarded  a $300K  incentive  fee. 

In  retrospect,  the  serialization  process  was  not  ideal  with  regard 
to  the  0S/MCMU  task.  The  reason  for  this  statement  involves  an  under- 
standing of  the  interface  between  the  applications  programs  and  the 
operating  system.  The  OS  work  required  modifications  to  the  old 
applications  programs  to  insert  "hooks"  for  use  by  the  OS,  even  though 
some  of  those  old  applications  programs  would  be  replaced  later  by  new 
ones  produced  during  the  LP  phase.  The  price  paid  for  some  "unnecessary" 
software  work  bought  an  early  assurance  that  the  all-MCMU  concept  was 
sound,  however,  and  it  appears  to  have  been  a good  decision. 
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The  last  element  of  the  incentivized  software  work  was  a series  of 
new  software  changes  for  the  LP  systems,  including  changes  to  the 
applications  programs,  operating  system,  and  Maintenance  and  Diagnostic 
(M&D)  programs.  These  changes  constituted  new  work  beyond  the  scope 
of  the  original  contract  and  amounted  to  about  $5M  on  the  LP  contract. 

A total  of  $200K  incentive  money  was  applied  here,  broken  down  into 
$100K  on  applications,  $60K  on  OS,  and  $40K  on  M&Ds,  each  effectively 
on  an  "all  or  nothing"  basis  rather  than  further  broken  down. 

The  mechanism  for  testing  for  accomplishment  of  the  LP  changes 
was  the  standard  Preliminary  Qualification  Test,  or  PQT.  Earlier 
experience  made  it  clear  that  PQTs  in  large  measure  determined  the 
system  to  be  delivered.  As  a consequence,  considerable  effort  went 
into  the  test  plan  defining  and  formalizing  the  PQTs  which  were  made 
subsets  of  the  Formal  Qualification  Tests  (FQTs).  As  structured,  the 
test  sequence  provided  for  early  visibility  into  the  LP  software. 

The  M&D  changes  were  the  first  to  be  completed  during  the  summer 
of  1976  and  the  only  area  in  which  no  major  problems  were  encoun+ered. 
The  biggest  problems  arose  in  making  the  required  changes  to  the 
applications  programs  which  were  due  to  be  completed  in  August  to 
qualify  for  the  incentive.  Slippages  occurred  finally  driving  the 
date  back  to  late  September. 

In  the  end,  the  contractor  received  the  full  incentive  fee  even 
though  this  had  been  on  the  all-or-nothing  basis.  Since  the  criteria 
had  not  formally  been  met  (slippages  had  occurred,  flow  charts  were 
not  delivered),  consideration  flowed  back  to  the  government  in  the 
form  of  additional  work  on  EPRs  that  had  been  determined  to  be  out 
of  the  original  scope.  So  for  its  $100K  the  government  received  about 
$65K-plus  of  additional  work. 

Much  of  the  credit  for  the  progress  now  being  made  on  TACFIRE 
software  must  go  to  the  cooperative  working  relationship  which  had 
developed  between  the  government  and  the  contractor,  and  the  controls 
instituted  through  the  new  software  management  plan.  The  arms-length 
relationship  had  given  way  to  a free  and  open  working  level  interchange. 
Technicalities  and  formalities  were  replaced  by  a "let's  figure  out  how 
to  get  the  job  done"  attitude  on  both  sides.  The  regularly  scheduled 
software  reviews  included  PM  personnel,  a user  representative,  and  a 
tester  (TECOM)  representative.  In  addition  to  contractor  management, 
actual  programmer  personnel  participated  directly.  All  of  these  were 
key  ingredients  for  successful  software  development. 

The  door  was  also  opened  in  November  1976  to  solving  the  long 
standing  problem  of  split  responsibilities  for  software  management. 

The  decision  had  finally  been  made  to  reassign  the  tactical  systems 
personnel  of  CSC  to  ART ADS.  Almost  immediately,  they  came  under  ART ADS 
operational  control. 
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On  balance,  the  LP  phase  software  incentive  program  must  be  viewed 
as  extremely  successful.  A tremendous  amount  of  good  work  was  accom- 
plished in  a relatively  short  period  of  time  (about  18  months)  with  a 
very  positive  effect  on  the  overall  TACFIRE  program.  The  combination 
of  knowledgeable  Government  management,  experienced  software  talent 
on  the  part  of  the  contractor,  and  incentive  money  well  applied  paid 
off  rather  well. 

Testing 


A Test  Integration  Working  Group  (TIWG)  had  been  formed  and  by 
August  1975  it  had  been  fairly  successful  in  implementing  the  concept 
of  conducting  a single  series  of  integrated  tests  as  opposed  to  many 
independent  (and  often  redundant)  tests  conducted  by  different  organ- 
isations for  different  purposes.  Earlier,  a significant  achievement 
had  been  accomplished  when  TACFIRE  successfully  interoperated  with  the 
AN/TPQ-37  Artillery  Locating  Radar  system. 

First  Article  Tests  (FAT)  for  the  LP  phase  were  scheduled  to  begin 
in  November  1976,  with  software  FQTs  and  systems  and  engineering  tests 
at  the  contractor's  facilities,  and  subsequent  field  tests  at  White 
Sands  Missile  Range.  These  would  be  followed  by  a Force  Development 
Test  and  Evaluation  (FDTE)  which  in  part  was  scheduled  in  response  to 
ASARC  guidance  to  conduct  a detailed  review  of  Field  Artillery  command 
and  control  requirements  and  an  analysis  of  potential  changes  in 
organization  and  doctrine  that  might  be  dictated  by  the  introduction 
of  TACFIRE.  Out  of  FDTE  would  come  the  decision  that  the  system  was 
in  fact  ready  to  be  turned  over  to  the  testers  for  conduct  of  DT/OT  III. 

First  Article  Tests  ran  essentially  as  scheduled,  beginning  on  the 
first  of  November  '76  and  concluding  in  the  8th  of  May  '77.  The  most 
serious  hardware  problem  that  arose  during  these  tests  was  with  the 
printer  which  had  already  been  the  subject  of  product  improvement 
efforts  as  a reliability  problem.  The  latest  problem  centered  on 
paper  handling  capabilities  in  the  tactical  environment.  The  printer 
subcontractor  was  hard  at  work  on  a modification. 

Software  problems  showed  up  during  FAT  also.  The  test  plan  and 
contract  structure,  however,  had  been  designed  to  accomodate  such 
problems.  A total  of  six  weeks  of  system  tests  were  called  for,  with 
the  start  date  contingent  on  the  successful  completion  of  FQT.  Provisions 
for  halting  the  tests  had  also  been  made.  Problems  uncovered  during  soft- 
ware FQTs  resulted  in  a six  week  slippage  in  the  start  of  the  system  tests 
which  thus  got  underway  on  28  February  1977.  By  the  15t,h  of  March  it 
became  apparent  that  enough  problems  existed  to  minimize  the  effectiveness 
of  further  testing  at  that  point.  The  PM,  however,  was  able  to  invoke 
the  provisions  of  the  contract  to  suspend  testing  and  commence  a mini 
Find,  Fix  and  Test  mode.  On  4 March,  FAT  was  resumed  by  rerunning 
portions  of  the  system  test  through  the  point  where  they  had  earlier 
been  halted.  This  time  they  proceeded  on  to  termination  with  few 
problems. 
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While  problems  had  arisen,  they  had  been  realistically  anticipated 
and  provisions  made  to  accomodate  them.  In  contrast  to  earlier  tests 
in  which  problems  had  caused  major  turmoil  in  the  program,  good  planning 
had  now  allowed  the  PM  to  retain  control  of  the  situation  and  generally 
maintain  the  overall  schedule. 

Mission  response  times  for  the  system  were  for  the  most  part 
significantly  improved  as  measured  during  FAT  and  compared  to  DT/OT  II 
figures.  In  most  cases  this  was  due  to  the  substitution  of  all  electron- 
ic MCMUs  for  the  slower  RAM  memories  with  their  inherent  electromechani- 
cal delays.  The  only  response  time  problem  areas  were  associated  with 
long  warning  messages  which  simply  required  a comparatively  long  time 
to  print.  The  actual  times  appeared  to  be  within  the  range  of 
acceptability  however. 

Continued  progress  was  being  made  on  the  all  electronic  Digital 
Message  Device  (DMD)  as  an  FFHED  replacement.  A contract  for 
15  engineering  development  models  had  been  let  in  August  1975  for 
delivery  in  September-October  1976.  A subsequent  contract  would  provide 
for  82  LP  models  for  use  in  DT/OT  III. 

FDTE  commenced  on  23  May  77  shortly  after  the  completion  of  FA.T. 

These  tests  proceeded  without  major  problems,  concluding  at  the  end 
of  July.  However,  they  did  not  fully  accomplish  the  objective  of 
validating  an  analysis  of  the  impact  of  TACFIRE  since  important  feeder 
studies  with  data  to  be  validated  had  not  been  completed  in  time.  The 
stage  was  now  set  for  DT/OT  III,  however,  with  DT  III  scheduled  to  run 
through  August  and  September,  and  OT  III  planned  to  begin  in  January 
1978. 

Planning  for  Full  Scale  Production 

It  had  become  apparent  to  the  PM  that  since  limited  production  of 
TACFIRE  would  be  completed  in  late  1977,  and  FSP  could  not  commence 
until  sometime  in  1979  at  the  earliest  (allowing  time  for  post  DT/OT 
III  analysis  and  the  ASARC/DSARC  Ilia  decision  process  prior  to  award, 
and  then  required  lead  times),  a serious  production  gap  would  occur. 

High  costs  are  associated  with  shutting  down  a production  line  and 
starting  it  up  again  some  time  later,  aside  from  the  potential  loss  of 
key  personnel  during  the  interim.  Accordingly  he  developed,  and  in  June 
1976  submitted,  a plan  to  bridge  this  gap  with  continued  LP  system 
production.  The  problem  was  intensified  by  a programming  and  budgeting 
decision,  made  in  January  1977,  which  delayed  an  FSP  target  award  date 
of  July  1978  to  October  1978  to  move  it  into  the  next  fiscal  year.  The 
PM's  plan  required  Congressional  approval  whi -h  was  requested  in 
January  1977  and  received  in  June.  The  distinction  between  LP  and 
LRIP  had  now  become  somewhat  blurred. 

It  had  been  the  PM's  plan  to  enter  into  separate  negotiations  with 
the  contractor  for  a new  contract  to  cover  the  additional  LP  phase. 
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The  CG,  DARCOM  directed  that  this  not  be  done,  but  that  it  be  negotiated 
as  a further  modification  of  the  original  contract.  The  rationale  for 
this  decision  was  that  the  Government  enjoyed  greater  leverage  with  the 
contractor  by  continuing  with  the  original  contract,  under  which  Litton 
still  had  unfulfilled  obligations.  Negotiations  took  longer  under  this 
arrangement,  but  probably  resulted  in  a better  deal  for  the  Government . 

Negotiations  were  completed  and  Mod  190  was  signed  on  30  September 
1977.  Under  the  new  contract  modification,  the  Mod  88  FSP  option  was 
restructured  into  five  separately  priced  options.  The  first  two  of 
these  were  aimed  at  filling  the  LP/FSP  gap  and  the  first  was  exercised 
immediately  to  produce  an  additional  8 sets  at  the  approximate  rate  of 
one  per  month  on  conclusion  of  LP.  The  second  would  later  permit  that 
to  be  extended  for  an  additional  10  sets. 

Development  Test/Operational  Test  III  ( DT/QT  III) 


DT  III  proceeded  generally  according  to  schedule.  From  the  PM' s 
ooint  of  view,  software  performance  was  very  good,  although  this  view 
was  not  shared  by  the  testing  community.  The  most  significant  problems 
were  corrected  by  a single  instruction  change  in  one  case,  and  replace- 
ment of  a defective  tape  cartridge  in  the  other.  (The  latter  actually 
turned  out  to  be  partially  a software  problem  also,  and  it  was  subse- 
quently corrected  with  relative  ease). 

A number  of  other  problems  had  been  encountered  during  testing, 
however,  and  numerous  corrections  had  been  made  to  the  software  tape 
version  being  utilized.  At  one  point,  TECOM  testers  at  White  Sands 
wanted  to  terminate  DT  III  testing  altogether.  TECOM  headquarters 
instructed  them  to  continue  to  assist  the  PM. 

It  had  been  planned  all  along  that  a new  software  tape  would  be 
prepared  for  0T  III,  incorporating  all  changes  effected  during  DT  III. 

As  a result  of  the  DT  III  testing  difficulties,  new  tapes  were  validated 
at  Ft  Sill  rather  than  White  Sands.  To  some  extent  this  compromised 
the  independent  tester  role,  although  the  operators  had  been  provided 
by  White  Sands.  The  PM  and  testers  remained  at  odds  over  the  conduct 
of  these  tests. 

In  November  of  1977,  an  informal  General  Officer  review  considered 
the  question  of  whether  or  not  the  system  was  ready  for  0T  III.  TECOM 
presented  a negative  picture  of  the  software  based  on  their  view  of  the 
DT  III  testing.  Their  position  was  rebutted  by  the  PM  who  had  confidence 
in  the  Ft  Sill  validations.  The  consensus  reached  at  that  meeting  was 
that,  0T  III  should  proceed. 

Hardware  reliability  once  again  arose  as  a problem  and  again  the 
printer  was  the  prime  villain.  The  DivArt.y  system  has  two  printers, 
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allowing  for  some  redundancy  which  reduces  down  time.  Its  DT  III  MTBF 
figure  of  171  hours  was  comfortably  above  the  150  hour  threshold.  The 
Battalion  set,  with  only  a single  printer,  saw  its  reliability  drop  to 
107  hours  MTBF,  below  both  the  150  hour  figure  and  a 105  allowance. 

These  figures  were  to  change  following  0T  III  to  95  hours  MTBF  for 
the  battalion  and  144  hours  for  the  division  set.  While  these  figures 
fail  to  meet  the  stated  requirement,  they  did  not  adversely  affect  the 
mission  performance  of  TACFIRE  during  the  conduct  of  0T  III,  which 
must  be  considered  as  the  acid  test  of  reliability.  One  must  also 
consider  that  the  magic  number  of  150  hours  JfTBF  was  in  reality  rather 
arbitrarily  established  many  years  earlier  and  inserted  into  the 
requirements  document.  The  prime  impact  of  the  lower- than-planned 
reliability  is  that  the  maintenance  workload  is  greater  than  antici- 
pated and  could  affect  the  personnel  requirements  of  the  system.  This 
would  have  to  be  reflected  in  the  overall  system  C0EA. 

Aside  froiti  the  reliability  problem.  0T  III  saw  TACFIRE  perform 
extremely  well  from  the  users'  point  of  view.  Fire  planning  was 
accomplished  to  a degree  the  manual  system  could  never  achieve  both 
in  quantity  and  quality  of  plans.  Thousands  of  targets  were  processed 
at  rates  that  only  a sophisticated  automated  system  could  begin  to 
handle.  Continuity  of  operations,  changes  in  support  role  assignments 
and  other  sophisticated  command/control  operations  were  performed  with 
relative  ease.  In  actual  live  fire,  TACFIRE  directed  thousands  of 
rounds  successfully,  with  greater  accuracy  and  flexibility  of  handling 
simultaneous  missions  than  the  manual/FADAC  system.  To  be  sure, 
several  areas  were  found  to  be  capable  of  being  improved,  but  no 
serious  shortcomings  were  encountered . In  short,  TACFIRE  proved  itself 
to  the  user  as  both  an  effective  and  necessary  automated  field  ar- 
tillery command/control  system. 

The  testers  once  again  had  a negative  vi ew  of  the  results.  Their 
chief  complaints  centered  on  maintainability  including  logistical 
support,  and  fire  mission  processing.  It  is  clear  that  TACFIRE  has 
not  achieved  the  MTFF  and  MTTR  figures  set  forth  in  the  QMR  nearly 
twenty  years  ago.  At  the  same  time  system  availability  has  proved  to 
be  more  than  adequate.  A higher  price  tag  in  terms  of  support  require- 
ments may  have  to  be  paid  to  realize  TACFIRE 's  benefits.  A number  of 
software  changes  have  been  made  to  improve  the  fire  mission  processing 
perf  ormance . 

VI . CURRENT  PROGRAM  STATUS 


As  this  study  is  written  TACFIRE  is  awaiting  its  final  ASARC  Ilia 
decision  point.  The  ASARC  is  scheduled  for  October  1978,  with  that 
date  dependent  on  the  completion  of  the  C0EA.  An  FSP  decision  should 
consider  C0EA  input  which  will  include  an  analysis  of  tradeoffs 
between  manpower  and  equipment,  potential  changes  in  organization  and 
doctrine,  and  the  potential  impact  of  an  equal  investment  in  additional 
weapons  and  personnel. 
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To  exercise  the  existing  contractual  FSP  options,  the  Government 
must  conclude  its  decision  process  in  time  for  a December  1978  award 
date.  A default  on  that  date  will  automatically  cost  millions  of 
R&D  dollars  due  and  payable  to  the  contractor,  as  well  as  increased 
procurement  costs  that  can  be  anticipated  if  it  becomes  necessary 
to  negotiate  a new  FSP  contract.  The  second  option  for  an  additional 
10  sets  has  already  been  exercised  to  keep  the  production  line  open 
through  the  projected  December  award  date;  no  additional  slack 
remains. 

TACFIRE  has  recently  come  under  criticism  by  a special  General 
Accounting  Office  (GAO)  study  group.  The  GAO  group  has  recommended 
that  FSP  be  delayed  pending  correction  of  numerous  hardware  and 
software  deficiencies  and  has  taken  exception  to  the  fact  that  the 
system  scheduled  for  production  is  not  the  system  that  has  been  tested. 

It  is  not  the  purpose  of  this  study  to  refute  the  GAO  points  or 
even  to  be  an  advocate  of  TACFIRE.  Nevertheless  it  must  be  said  that 
in  researching  the  information  to  be  presented  in  this  case  study, 
little  was  found  that  could  support  the  conclusions  of  the  GAO  study. 
The  argument  about  differences  in  the  production/tested  systems  may 
have  some  validity,  but  it  does  not  appear  to  make  good  economic 
sense.  Pressures  for  competition,  improved  performance,  and  maintain- 
ing state-of-the-art  have  resulted  in  numerous  changes  to  Individual 
items  of  TACFIRE  equipment.  Additional  changes  can  be  anticipated  in 
the  future  as  well,  since  TACFIRE  will  continue  to  be  a dynamic 
evolving  system.  Certainly  testing  is  called  for  when  substitutions 
are  made.  The  amount  of  testing  required  for  any  one  item  change 
will  depend  on  the  criticality  of  the  item  and  the  relative  costs  of 
testing.  A system  test  comparable  to  a DT/OT  sequence  is  neither 
necessary  nor  affordable.  The  same  can  be  said  for  any  equally  large 
and  complex  system. 

The  current  software  status  is  exceptionally  good.  The  handful 
( 7 as  of  31  May  1979)  of  current  deficiencies  must  rank  TACFIRE  as  one 
of  the  best  software  systems  ready  for  deployment.  Compared  to  most 
commercial  systems  of  similar  complexity,  TACFIRE  has  an  order  of 
magnitude  fewer  deficiencies.  The  nature  of  the  software  beast  is 
that  a zero  defects  level  is  rarely  achieved,  and  when  claimed,  more 
often  than  not  is  indicative  of  inadequate  testing  rather  than  super- 
clean software. 

Only  one  major  new  software  release  will  be  delivered  by  the  con- 
tractor. Following  that,  the  Government  feels  it  is  prepared  to  accept 
full  responsibility  for  subsequent  software  maintenance,  with  a support 
facility  already  in-being  at  Ft  Sill,  OK.  If  successful,  an  early 
transitioning  of  software  support  responsibility  would  also  be  a 
major  accomplishment. 
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VII.  SUMMARY  AMD  CONCLUSIONS 


By  any  objective  standards,  TACFIRE  must  be  considered  to  be  a 
success  story,  particularly  from  the  software  point  of  view.  When 
one  discounts  the  difficulties  of  the  early  years  of  comparative 
ineptness  on  both  the  contractor  and  government  sides,  the  ensuing 
years  saw  closure  on  effective  development  and  management  techniques. 

Several  points  raised  through  this  study  merit  attention  and 
review  by  project  managers  and  system  developers.  The  first  of  these 
is  the  concept  of  a "Find,  Fix,  and  Test"  mode  and  the  developer/ 
tester/user  interfaces  involved.  Related  to  this  is  the  critical 
role  to  be  played  by  a formal  "designated  user."  The  importance  of 
knowledgeable  and  experienced  software  managers  has  been  cited, 
along  with  examples  of  good  and  bad  incentive  structures.  These  are 
the  major  items  which  have  contributed  to  the  success  of  the  TACFIRE 
development . 

This  study  also  suggests  that  testing  philosophy  needs  further 
examination  on  several  fronts.  The  testing  system  has  still  not 
matured  in  its  understanding  or  accomodation  of  software  based 
systems.  A "perfect"  software  system  of  any  magnitude  with  zero 
deficiencies  has  yet  to  be  developed,  either  in  the  commercial  world 
or  within  the  military.  Much  research  is  ongoing  aimed  at  formal 
proofs  of  software  "correctness",  but  the  state-of-the-art  for  the 
foreseeable  future  will  fall  short  of  this  objective.  In  the  meantime, 
management  decisions  must  be  based  on  enlightened  qualitative  judgments 
rather  than  a simple  quantitative  tally  of  deficiencies. 

Another  area  of  concern  is  the  question  of  who  it  is  that  the 
system  developer  must  satisfy.  Unfortunately  there  are  many  diverse 
players  who  do  not  speak  with  one  voice.  On  the  one  hand,  TRADOC  may 
appoint  a designated  user  or  TRADOC  System  Manager  (TSM)  to  work  with 
the  system  developer.  Yet  not  infrequently  Forces  Command  (FORSCOM) 
or  US  Army  Europe  (USAREUR),  for  example,  may  have  a very  different 
point  of  view.  Who  is  the  "real"  user?  DARCOM  has  its  own  independent 
development  tester  in  TECOM,  while  OTEA  performs  an  independent 
operational  testing  function.  These  agencies  are  supplemented  with 
others  to  perform  analyses  and  independent  reviews,  such  as  the  Army 
Materiel  Systems  Analysis  Agency  (AMSAA)  and  the  TRADOC  Systems 
Analysis  Agency  (TRASANA).  A unique  testing  function  is  also  performed 
within  TRADOC  by  the  Combined  Arms  Test  Activity  (TRACATA),  and  the 
many  TRADOC  boards  have  their  own  opinions  of  what  a system  should  be 
and  what  its  demonstrated  performance  has  been.  Moving  up  to  the  DOD 
level  still  others  come  in  to  play,  not  to  mention  the  GAO  and  Con- 
gressional staffers.  If  this  paragraph  has  confused  the  reader,  than 
it  has  accomplished  its  purpose.  This  is  the  project  manager's 
dilemma. 

TACFIRE  is  not  yet  out  of  the  administrative  woods  and  a few 
remaining  major  hurdles  must  be  cleared.  From  the  technical  management 


point  of  view,  the  system  has  arrived.  The  gestation  period  has  been 
about  twenty  years,  but  the  baby  is  alive  and  well.  Hopefully,  it 
will  soon  be  in  the  hands  of  the  troops. 


APPENDIX  A 


TACFIRE  SOFTWARE 

This  appendix  contains  a description  of  the  individual 
TACFIRE  computer  programs.  It  is  divided  into  three  sections 
covering  Applications  Programs,  Operating  System,  and 
Maintenance  and  Diagnostic  Programs. 
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TACFIRE  SOFTWARE 


I . Applications  Programs 

At  the  battalion  center  an  Ammunition  and  Fire  Unit 
Status  program  maintains  current  status  information  for  all 
fire  units  including  their  mission,  location,  weapon 
strength  and  the  types  and  quantities  of  ammunition  avail- 
able. Meteorological  data  are  received,  used  and  distributed 
according  to  the  needs  of  the  battalion.  Support  maintains 
current  geometry  data  including  zone  of  responsibility,  front 
line  trace,  no  fire  line,  fire  coordination  areas,  dead 
space  areas  and  air  corridors.  Tactical  and  Technical  Fire 
Control  produces  a detailed  analysis  of  each  target  and 
recommends  the  fire  unit(s),  number  of  rounds  and  type  of 
ammunition  necessary  to  defeat  a target.  All  of  this  is 
accomplished  considering  the  availability  of  ammunition  and 
the  capability  of  each  fire  unit,  as  well  as  safety  limits, 
no  fire  lines  and  other  control  parameters.  The  computation 
also  produces  ballistic  data  using  meteorological  and  other 
information  about  nonstandard  and  existing  conditions.  The 
computer  center  provides  complete  and  accurate  fire  commands 
to  the  firing  batteries.  The  Fire  Planning  program  will 


consider  up  to  15  fire  units  and  150  targets,  analyze  each 
target  for  defeat  against  the  fire  unit(s)  and  ammunition 
available  and  produce  a complete  schedule  of  fires.  In 
addition,  a complete  ballistic  solution  is  generated  for 
each  fire  unit  target  pair  and  transmitted  digitally  to  each 
firing  unit.  The  Artillery  Survey  program  provides  compu- 
tations necessary  to  carry  survey  control  forward  to  battery, 
forward  observer,  target  acquisition  devices  and  target  areas. 

At  Division  Artillery  the  operational  programs  are  similar 
to  those  at  battalion  but  expanded  to  provide  computations 
at  this  higher  echelon.  The  Ammunition  and  Fire  Unit  Status 
Program  maintains  status  information  on  DivArty,  Corps 
Artillery,  Air  Force  and  Naval  Units.  Meteorological  and 
Support  data  are  maintained  for. useby  DivArty  and  FSE. 

Tactical  Fire  Control  provides  defeat  criteria  for  targets 
at  the  Division  level.  Fire  Planning  is  expanded  over  what 
is  available  at  battalion  to  include  incorporating  the  nuclear 
fire  plan  prepared  by  FSE.  Artillery  Survey  permits  survey 
information  centers  at  DivArty  to  disseminate  survey  control, 
recompute  survey  information  to  establish  common  grids,  maintain 
trig  lists  and  perform  artillery  survey  computations.  In 
addition,  and  Artillery  Target  Intelligence  program  provides 
for  the  complete  processing  of  target  information  from  all 
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sources.  The  computer  correlates  all  target  reports, 
combines  related  reports  when  appropriate  and  provides  the 
most  probable  location  and  description  of  each  target. 

The  result  is  a complete,  current  and  accurate  target  list 
at  all  times.  This  target  list  can  then  be  provided  to  the 
fire  planning  routines  at  battalion,  DivArty  and/or  FSE . 

The  FSE  programs  reside  in  the  DivArty  computer  and  share  the 
Ammunition  and  Fire  Unit  Status,  Artillery  Target  Intelli- 
gence, Meteorological  and  Support  Functions.  In  addition, 
other  operational  programs  are  provided.  Preliminary  Target  \ 

Analysis  determines  the  most  effective  means  of  attacking 
targets,  considering  the  capabilities  within  Division 
Artillery  and  the  delivery  means  at  Corps  and  Army,  as  well 
as  tactical  air  and  naval  gunfire,  when  appropriate.  The 
analysis  considers  high  explosive,  chemical,  nuclear  and 
special  munitions.  Based  on  these  considerations  and  on 
guidance  criteria  established  by  the  commander , the  computer 
recommends  the  best  munition  and  delivery  means  to  defeat 
specific  targets.  Nuclear  Target  Analysis  provides  for  a 
detailed  nuclear  target  analysis  considering  commander's 
criteria,  contingency  and  safety  factors,  availability,  and 
allocation/assignment  parameters.  The  analysis  produces  a 
recommended  selection  for  each  target,  which  includes  the  fire 
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unit,  yield,  height  of  burst  and  desired  ground  zero.  In 
addition,  the  computer  displays  the  fraction  of  casualties 
which  can  be  expected  and  is  capable  of  displaying  other  data 
such  as  safety  radii,  radius  of  damage  and  maximum  displace- 
ment. This  program  performs  vulnerability  analysis  and 
damage  assessments  for  both  enemy  and  friendly  bursts. 

Nuclear  Fire  Planning  then  determines  an  optimum  schedule  of 
nuclear  fires  within  established  criteria  including  pre- 
initiation factors.  Chemical  Analysis  determines  the 
casualty  level  which  can  be  achieved  and  produces  a recommended 
selection  for  each  target.  This  recommendation  will  include 
fire  units,  chemical  agent  chosen,  number  of  rounds  required, 
type  of  attack,  desired  points  of  impact  and  height  of  burst. 
Fallout  Prediction  combines  inputs  from  assumed  or  actual  cloud 
measurements  with  meteorological  data,  and  fallout  patterns 
are  predicted. 

I I Operating  System 

The  hardware,  software,  communications,  security  and  all 
the  rest  of  the  TACFIRE  components  are  integrated  into  a 
cohesive  system  through  a sophisticated  operating  system. 

It  is  responsible  for  the  real-time  running  of  the  application 
and  Maintenance  and  Diagnostic  programs  in  response  to  input 
messages  from  the  various  TACFIRE  devices.  It  also  formulates 
and  distributes  the  necessary  output  to  the  appropriate  addressees. 
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The  operating  system  is  functionally  divided  into  three 


categories:  The  stimulus  receiver;  the  executive;  and  the 

supervisors.  The  stimulus  receiver  is  responsible  for 
handling  interrupts.  An  interrupt  is  a signal  that  controls 
the  hardware  by  signifying  that  a particular  device  is  ready 
to  begin  processing  or  that  processing  has  been  completed. 

Through  the  use  of  interrupts,  the  stimulus  receiver 
performs  automatic  priority  processing.  This  function  insures 
that  high  priority  tasks  such  as  fire  missions  are  processed 
before  lower  priority  ones.  It  also  provides  for  time 
dependent  functions  such  as  performing  periodic  loop  checks 
on  the  equipment  and  maintaining  the  time  of  day. 

The  stimulus  receiver  also  provides  the  interface  between 
the  computer  and  the  peripheral  devices  such  as  the  Digital 
Plotter  Map,  Electronic  Tactical  Display,  and  Electronic 
Line  Printer.  The  Executive  performs  resource  allocation  for 
all  TACFIRE  programs.  A resource  is  anything  in  the  system 
which  must  be  shared  by  the  software  such  as  the  central  pro- 
cessor, execution  time  and  the  various  input/output  devices. 

These  resources  are  managed  by  the  executive  on  a multi-programmed 
basis;  that  is,  two  or  more  tasks  running  in  an  interleaved 
fashion  by  sharing  these  available  resources. 
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The  supervisors  provide  the  housekeeping  functions  necessary 
for  the  orderly  receipt,  storage  and  transmission  of  messages. 
The  data  management  function  controls  the  allocation  and 
storage  of  files  in  memory.  The  message  processing  super- 
visor verifies  the  authenticity  of  a message,  posts  a 
warning  if  the  message  is  from  an  unauthorized  source  and  logs 
the  message.  It's  also  responsible  for  message  traffic  over  the 
digital  data  terminals.  For  outgoing  messages,  it  breaks 
them  into  segments,  if  necessary,  initiates  the  transmission 
of  each  segment  and  receives  an  acknowledgement  from  the 
receiving  station  that  the  message  has  been  received.  Incoming 
messages  are  checked  for  proper  addressing  and  completeness. 

If  the  message  is  proper,  the  message  processor  sends  an 
acknowledgement.  Otherwise  it  generates  a warning  message. 

The  Artillery  Control  Console  support  supervisor  responds  to 
operator  requests  thus  providing  the  man-machine  interface. 

Ill  Maintenance  and  Diagnostic  Programs 

Reliability  standards  of  the  TACFIRE  system  are  achieved 
in  part  through  the  use  of  a Maintenance  and  Diagnostic  (M&D) 
software  package.  The  M&D  programs  are  constantly  running  so 
that  equipment  faults  are  rapidly  detected.  Additional 
programs  can  then  be  initiated  which  isolate  the  fault  to  a 
small  group  of  digital  cards  within  the  faulty  device.  Using 
a fault  catalogue  and  a GO  - NO  GO  built  in  circuit  card  tester, 
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the  failed  card  is  then  found  and  replaced.  When  a fault 
is  detected  within  a computer  center,  graceful  degradation 
occurs  when  possible.  Thus,  mission  processing  can 
continue  and  repair  deferred  until  the  tactical  situation 
permits.  In  the  event  that  a computer  center  fails 
completely,  a lateral  backup  capability  exists  so  that  an 
adjacent  computer  center  can  immediately  assume  the  mission 
of  the  failed  computer.  Thus,  TACFIRE  is  a highly  reliable 
tactical  system  capable  of  providing  uninterrupted  mission 
processing  under  combat  conditions. 


USER  DETERMINATION  ITEMS  (UDI's) 


This  appendix  contains  two  representative  TACFIRE  User 
Determination  Messages.  Message  Nr.  1 is  dated  30  August  1972. 
Message  Nr.  41  is  dated  18  January  1978.  Due  to  its  length, 
portions  of  Message  Nr. 41  have  been  omitted. 
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SUBJ1  TACFIRE  USER  DETERMINATION  msg  NR  1 

A.  REF  KSG  HO  OA,  DAFO-DC.  SUBj:  TACFIRE,  DT  G I 7 22  *•  72  AU  C 72. 

1*.  IN  COMPLIANCE  V/REF  HSG,  THE  TOE  U".rR  0 E T C.R  MIRATIONS  HAVE  CEEN 

hade: 

■ HEM  I -1  : DCrTCIFNT  AREA  - OMR  PARA  70  A?  1 ( A)  IF  (?9(2)U)?G>  STATES 
THAT  BN  (DIVARTT1  TACFIRE  COMPUTER  SHALE  BE  CAPABLE  OF  COMM 
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SIMULTANEOUSLY  ON  12  (20  TOR  OIVARTY)  HALF  DUPLEX  CR  FULL  DUPLEX 
COMM  CHANNELS  (FLD  VIRE  OR  RAOIO)  V/OTHER  COMPUTER  CEN  AND  REMOTE 
DEVICES  ON  REAL-TIME  eASIS.  SUF  SPACE  MUST  BE  PR OV  IN  VEHICLE  TO 
PERMIT  INSTL  OF  12  <20  FOR  OIVARTY)  DATA  MODEMS  VO  COMPROMISING 
OP  SPACE  RQRMTS  AND  VO  UNDUE  ELECTRICAL  ALTERATION.  ARTY  BN  AND 
DIVARTY  COMPUTERS  HAVE  ONLY  4 DIGITAL  DATA  TERMINALS  EA.  ONLY  J 

comm  channel  <vire  or  radio)  is  prov  by  ea  data  terminal.-  thus  bn/ 

DIVARTY  FDC  CEN  ARE  PROV  V/ONLY  4 CHANNELS  EA  (CPR'S  KE  37 , OE  344  ) 
USER  DETERMINATION  - 4 COMM  CHANNELS  VILL  NOT  SAT  COMM  R OR KT S AT 
BN  FDC'S  OR  DIVARTT.  VO  RADIO/VIRE  INTEGRATION  CAPABILITY,  MIN  OF 
9 DIGITAL  DATA  TERMINALS  (DOT'S)  ARE  R OR  AT  BN.  SHOULD  RADIO/VIRE 
INTEGRATION  CAPABILITY  BE  PROV,  G DDT'S  WOULD  SAT  CURRENT  BN  RORHT. 
INTEROP  RQRMTS  V/OTHCR  DIGITAL  DATA  SYS  ITOS)  DICTATE  NEED  FOR  2 
ADO  DOT'S  IN  FUTRUE.  BN  CONFIGURATION  CES  BY  USER  IS  RADIO/VIRE 
INTEGRATION  DEVICE  SUCH  AS  MONITORING,  PATCHING,  A NO  CONTROL  UNIT 
(HPCU)  V/G  DDT*  S AND  V/PROVISIONS  TO  ADD  2 DDT'S  IN  FUTURE.  AT 
DIVARTY.  CURRENT  RORHT  IS  7 DDT'S  VO  RADIO/VIRE  INTEGRATION.  OR  S 
V RADIO/VIRE  INTEGRATION.  PROV  TO  ADD  2 DOT'S  AT  OIVARTY  IS 

also  rqr.  ' 

ITEM  1-?:  OrriCI ENT  AREA  - TACFIRE  CONS  ICH  FIRST  WHEN  PERS  TGT  IS 
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ATK.  I CM  is  always  more  eft  than  any  othep  shell/fuze  coho  against 

PEPS.  THEREFORE  TACFIRE  ALWAYS  CHOOSES  ICU  UNTIL  ICM  IS  EXHAUSTED. 
UNLESS  FIRE  MSN  IS  RECOMPUTED  USING  ALTER  OPTION.  CKDRS  HOD  MS G DO 
NOT  PROV  MEANS  TO  REORDER  FROJ/FUZE  CONS  ORDER.  SINCE  LARGE  AMTS  OF 
ICH  ARE  NOT  NORM  AVAIL  DUE  TO  COST  OF  RD.  A CROP  SHOULD  HAVE  MEANS 
OF  REORDERING  SELECTION.  (EPR  L4  - 4 34  ) 

USER  DETERMINATION  - CMOR’S  HO D SHOULD  ?E  CH  TO  IUCL  A HK 0 SELECTION 
CRITERIA.  THIS  WILL  ALLOW  CMDR  TO  JNFL  Uf  ?!C  t ■ CHOI  CC  OF  AH  NO  WO 
HAVING  TO  DELAY  PROCESSING  DY  RE  CO  HP UT A T 10 N. 

ITEM  1-3:  OLTICirM  AREA  ~ H1L-STD-1472A  , PARA  S.7.3.4.  pr  0 VFRT 
ADJ  FOR  SEAT  IS  FROM  1G  TO  21  IN.  SEAT  IN  BN  AND  DIVARTY  SHELTER 
HAS  VERT  ADJ  rR  OH  17-1/2  TO  21  IN.  (EPR  L4-314) 

USER  DETERMINATION  - PRES  SEAT  ADJ  IS  S»T. 

2.  FROM  USCR'S  STCPT.  FOL  GEN  PRIORITY  ORDERING  APPLIES  TOR  CORR 
DEF  AND  SHORTCOMINGS  I DENT  IN  CPR'ST 

* 

A.  TIRST.  THOSE  DEF  WHICH  HAMPER  CONT  OF  ET/EST. 

B.  SCCONO.  THOSE  DEF  WHICH  DO  NOT  HAMPER  CONT  OF  ET/EST  BUT 
WHICH,  ir  NOT  CORR  PRIOR  TO  END  OF  ET/EST.  WILL  CAUSE  FINDING  OF 
UNSUITABILITY. 

c.  third,  all  others. 
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ZEN/C  TACFIRE  FIELD  0 FT  SILL  OK//DRCFM-TDS- 
TF-FS// 

ZEN/CDRTCATA/ATTN:  ATCAT-CAD-TF/FT  HOOD  TX// 
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SUBJECT:  TACFIRE  (DMD)  USER  DETERMINATION  MESSAGE  NO.  41 

A.  LTR,  HQDA , DAFD-DOT,  7 SEP  73,  SUBJECT:  TACFIRE  PROGRAM 
STRUCTURE. 

B.  MSG,-  USAFACFS , ATSF-CT-ME,  6 APR  73,  SUBJECT:  TACFIRE  TERMS 
•>F  REFERENCE. 

C.  PRIME  ITEM  DEVELOPMENT  SPECIFICATION  FOR  DMD  FOR  TACFIRE,  EL- 
SS-2603-7F,  7 APRIL  1975. 

ITEM  NO.  41-1:  DEFICIENT  AREA:  BATTALION  SYSTEM  FAILED  TO  GEN- 
ERATE WARNING  ON  RECTANGULAR  REPLOT  WHEN  QE  CHANGE  WAS  LESS 
THAN  1 MIL.  (L4-3638). 

USER  DETERMINATION:  CURRENT  SYSTEM  DESIGN  AND  OPERATION  IS 
ADEQUATE. 

RATIONALE:  THE  TARGET  LOCATION  IS  CORRECTED  IN  THE  FM  TILE  AS  A _J 
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ALL  FU  SPECIFIED  IN’  FM;  CAP  ANALYSIS.  (L4-364.Q1. 

USER  DETERMINATION : CURRENT  SYSTEM  DESIGN  AND  OPERATION  IS 
CORRECT. 

RATIONALE:  THE  USE  OF  UFFES  WITH  THE  FM;  CAP;  MESSAGE  LIMITS 
CONSIDERATION  TO  ONLY  THOSE  UNITS  SPECIFIED.  THE  PROBLEM  DESCRIBED 
CANNOT  BE  REPRODUCED  ON  VERSION  if 82  MASTER  TAPE.  VERIFICATION 
OF  CURRENT  PROCESSING  ON  VERSION  £32  TAPE  WAS  RUN  ON  9 DECEMBER 
1977  AND  14  DECEMBER  1977.  THE  EPR  SHOULD  BE  WITHDRAWN  AS  NON- 
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ITEM  NO.  41-21:  DEFICIENT  AREA:  RFAF : X WAS  INCORRECTLY  GENERATED 
ON  TARCET  WHICH  HAD  BEEN  DEFEATED.  (1.4-3613)  . . 

USER  DETERMINATION:  CURRENT  SYSTEM  DESIGN  AND  OPERATION  IS 
CORRECT. 

(f;  RATIONALE:  SEVERAL  ATTEMPTS  WERE  MADE  ON  VERSION  !! 82  TAPE  TO  RE-CREATE 
THE  PROBLEM  AND  THE  SYSTEM  IS  OPERATING  CORRECTLY  ON  14  DEC  77. 

THE  EPR  SHOULD  BE  WITHDRAWN  AS  NON-REPRODUCIBLE. 

ITEM  NO.  41-??:.  DEFICIENT  AREA:  SYSTEM  FAILED  TO  PRODUCE  MFR 


EN  MISSION  WAS  ENDED  FOR  FU  WHICH  BECAME  OUT  OF  RANGE  DURING 
iu/JUSTMENT.  (L4-3585). 

USER  DETERMINATION:  CURRENT  SYSTEM  DESIGN  AND  OPERATION  REQUIRES 
CORRECTION. 


RATIONALE:  WHEN  FIRE  MISSIONS  ARE  ENDED  FOR  ANY  FU,  THE  MFR 
SHOULD  BE  PRODUCED  IN  ORDER  TO  PROVIDE  FOR  PROPER  AMMUNITION 
ACCOUNTING. 

ITEM  NO.  41-2  3:  DEFICIENT  AREA:  KG  ALARM  FAILURE  OVEPvLOADS  THE 
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COMMUNICATIONS  NETWORK.  (1.4-3737) . 
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USER  DETERMINATION : CURRENT  SYSTEM  DESIGN  AND  OPERATION  IS  CORRECT. 
RATIONALE:  THE  PROBLEM  DESCRIBED  IN  THE  EPR  WAS  CORRECTED  EY 
SOFTWARE  Ita’LEMENTATION  OF  ECP  504  ON  MASTER  TAPE  VERSION  080.  A 
HARDWARE  RETROFIT  OF  CABLES  IS  PRESENTLY  UNDERWAY  FOR  ALL  SYSTEMS 
AND  WILL  BE  FINISHED  PRIOR  TO  THE  START  OF  OT  III.  THE  EPR  SHOULD 
BE  DOWNGRADED  TO  INFORMATION. 

ITEM  NO.  41-24:  DEFICIENT  AREA:  SYSTEM  REQUIRES  INTERVENTION 


TO  CORRECT  MESSAGE  FORMAT  RECEIVED  FROM  REMOTE  SUBSCRIBERS. 
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CLASSIFICATION  IS  REQUIRED". 

RATIONALE:  NUCLEAR  UPDATE  STATEMENT  OF  CORK  INCLUDES  CORRECTION 
OF  THIS  DATA. 

ITEM  NO.  41-29:  AMENDMENT  TO  MESSAGE  032,  12  JULY  1976. 

USER  DETERMINATION  ITEM  32-6  RATIONALE  IS  AMENDED  TO  DELETE  THE 
FOLLOWING:  "DIM  CLASSIFICATION  IS  REQUIRED  FOR  OPERATOR  PERSONNEL 
AND  ANALYSTS." 

RATIONALE:  NUCLEAR  UPDATE  STATEMENT  OF  WORK  INCLUDES  CORRECTION  OF 
TIIS  DATA. 
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APPENDIX  C 


FIND,  FIX,  TEST  MODE  MEMORANDUM  OF  AGREEMENT 

This  appendix  consists  of  a copy  of  the  actual  Memorandum 
of  Agreement  between  the  PM,  ARTADS  and  Litton  Data  Systems 
Division  covering  the  mode  of  operation  in  effect  during 
the  TACFIRE  Find,  Fix  and  Test  mode. 
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SUBJECT:  HUH,  FIX,  TEST  MODE  ( FFIM)  OF  Operation 


29  March  1973 


^OPE: 

1.  Upon  the  signing  of  the  TACFJRE  Contract  Modification  Number  P00088  by 
signatory  parties,  the  present  government  test  mode  will  be  discontinued  and  a Find, 
Fix,  Test  Mode  (FFIM)  initiated.  Broad  guidelines  as  to  the  ground  rules  under 
which  the  FFIM  will  proceed  ate  as  outlined  herein.  The  FFTM  will  extend  'from 

date  of  execution  of  the  Contract  Mod  until  the  start  of  the  government  Systems 
Integration  Test. 

2.  At  FFIM  start  date  equipment  conf i gurati  on  at  Fort  Sill  and  at  Uhi te  Sands 
Missile  Range  (V.'oMIi)  are  predicted  to  he  as  follows: 

a.  Fort  Sill  - Ei'/EST  Divhrty  and  A Bns. 

b.  WSMR  - TSS  DivArty  augmented 

3.  Within  two  weeks  of  start  of  the  Fl’TM  one  Bn  with  out-  of- shel  ter  kit  and  BLU 
(less  personnel,  KG  and  GFE  used  outside  of  the  shelter)  will  be  shipped  to  Litton, 
Van  I.'uy?  ar,d  one  complete  Bn  system  will  be  shipped  to  WS'lR. 

4.  Tasks  to  be  "accomplished  during  the  FFTM  include: 

a.  I)T.M  r;-jvi  to  !">v  ennfr^r^or  norcnnnri  1 ? t?  be -rdcr t-!%cn  the  77  7/ 

•»  frae.  This  effort  will  involve  support  by  government  personnel.  Operator 
maintenance  personnel  input  as  well  as  equipment  time  for  tool  proofing  will 
oe  required.  These  operations  will  be  dovetailed  with  the  FFTM  and  accomplished 
in  parallel  with  such  operations  to  preclude  impact  thereon. 

b.  During  the  FFTM  the  contractor  will  endeavor  to  fix  all  known  softv.’are 
problems.  The  contractor  will  be  permitted  to  take  leniencies  with  the  system, 
tapes  (i.o.:  access  patches)  in  order  to  facilitate  and  expedite  the  fielding 

of  solutions  to  problems.  System  tapes  so  modified  shall  not  be  used  for  government 
verification  of  fixes  or  ET  tests. 

c.  During  the  FFTM  the  Government  will  ’verify  that  software  problems  have 
in  fact  been  corrected.  Tapes  supplied  to  the  government  for  checkout  and 
determination  of  contractor  progress  must  be  under  configuration  management  and 
have  been  processed  through  the  presently  established  tape  verification  procedures 
in  the  Van  Nuys  facility. 

d.  During  the  FFTM  the  contractor  will  deliver  the  software  packages  to 
implement  the  COMSEC  procedures,  FSO  procedures  and  the  necessary  software  to 
permit  use  of  the  new  devices.  The  provisions  of  paragraphs  b and  c above  will 
apply. 
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..  e.  During  the  FFTM  the  contrnrtor  will  Lake  the  actions  necessary  to  correct 
current  hardware  deficiencies  and  introduce  replacement  and/or  retrof i tted. .devices. 
Equipments  transported  between  field  sites  and  the  contractor  facility  for  repair, 

/ -«trofit  or  new  device  engineering  will  be  moved  in  an  expedited  fashion.  All 

rofitted  equipments  returned  to  the  field,  or  retrofits  performed  in  the  field, 
.st  be  discreetly  marked  and  accompanied  by  appropriate  documentation . Rigid 
management  of  changing  equipment  configurations  by  both  the  contractor  and  the 
government  must  be  maintained  in  order  to  track  progress  toward  complete 
establi  shiscnt  of  the  DT/OT  11  baseline  configuration. 

f.  During  the  FFTM  the  government  will,  as  possible,  verify  that  hardware 
deficiencies  have  in  fact  been  corrected.  Although  at  both  Fort  Sill  and  WSUR 
the  l’FTM  will  be  the  primary  effort,  the  government  will  on  a non-interfercnce 
basis  conduct  ycrifj.catlon-_tcsting.  and  other  new  testing  that  may  be  required  to 
qualify  the  TACFJRE  system. 

g.  Formal  and  OJT  of  newly  assigned  government  operator  and  organizational 
maintenance  personnel  will  be  conducted  during  the  FFTM  time  frame.  It  is  the 
government ' s intent  to  accomplish  this  training  on  a non-interference  basis  with 
FF’IM  operations.  These  operations,  in  turn,  must  minimally  impact  on  the  training 
operations.  Therefore,  the  government  and  the  contractor  mutually  agree  that  an 
the  switch-over  of  operations  every  attempt  will  be  made  to  leave  the  svste  s in 
readiness  for  the  subsequent  operation.  General  Plan  of  training  to  be  concreted, 
locations  and  schedule  is  at  Incl  1. 

5.  General  approach  to  operation  during  the  FFTM  will  be: 

a.  At  each  test  site  the  government  will  provide  2 (1  PM  ARTADS,  1 TECCU) 

r]  fh  P rr>"f  r,i  rf-or  nr*p  lnrHin'Hnnl  t r>  rOTT'p  7?  S?  ?.  FFTM  CcrM-TCl  Tc^ir.;.  Tl'C”  *.;i]  1 '.  '.'.Z  Z t. 

jlarly  to  discuss  requirements,  schedules,  plans,  differences,  etc.  Whenever 
, -ssible  utilization  of  equipment  will  be  planned  at  least  one  week  in  advance. 

The  government  will  provide  the  necessary  operators,  supervisors  and  evaluators, 
within  reason,  to  insure  completion  of  the  objectives  outlined  by  the  contractor. 
The  contractor  will  have  on  hand  sufficient  supervisory,  engineer,  analyst,  and 
software  expertise  to  support  these  objectives  and  adequately  complement  government 
personnel . 

b.  During  FFTM  organizational  and  DS/C.S  Maintenance  will  be  performed  by 
contractor  personnel  with  assistance  as  required  from  government  personnel.  Either 
by  observation , report,  or  other  means  government  evaluators  must  be  informed,  in 
detail,  of  all  maintenance  actions.  Use  of  parts,  float,  and  flow  of  material  to 
and  from  depot  maintenance  will  follow  already  established  procedures. 

c.  When  problems  are  encountered  processing  will  be  interrupted  only  long 
enough  to  gather  that  data  necessary  to  support  an  EPR. 

d.  System  output  and  dumps  from  FFTM  will  be  available  for  the  contractor 
after  appropriate  security  requirements  arc  met.  Arrangements  for  copies  for,  or 
transfer  to,  the  government  for  its  investigations  will  be  madeon  an  individual , 

as  requested  basis.  Output  and  dumps  from  government  test  periods  will  be  piovided 
the  contractor  on  an  as  requested  basis. 


0-3 


IHiS  PAGE  IS  BEST  QUALITY  PRACIIGABL1 
FROM  COPY  FURNISHED  TO  DOC  


c.  Government  analyses  of  system  output;;  will  l>e  provided  contractor  personnel 
expedi  Liously  in  order  to  insure  rapid  corrective  action  of  expected  probleins. 

f.  Government  produced  run  logs  will  be  provided  contractor  personnel  on  a 
illy  basis.  Consolidated  maintenance  fonns  will  also  be  provided  as  required. 

g.  In  the  event  of  failure  in  a given  DivArty  or  Bn  system  and  no  contractor 
personnel  appear  within  one  hour  on  site  to  remedy  the  failure,  the  government  rr.ay, 
at  its  discretion,  cease  operations  on  that  system  for  the  remainder  of  the  sh^ft. 

In  the  event  the  agreed  to  numbers  of  contractor  personnel  are  on-site  working  in 

another  area  the  above  will  not  apply. 

• 

h.  Periods  ns  indicated  in  Inclosurc  2 will  be  devoted  to  government  designated 
activities  primarily  aired  at  review,  check,  and  test  of  contractor's  progress  in 
correcting  faults  and  conduct  of  ET.  During  these  periods  the  governrr.cn t will 
operate  the  equipment.,  pull  scheduled  and  deferred  maintenance,  and  be  the  pr.  ary 
force  in  the  control  of  operations.  Contractor  personnel  n.i-  monitor  govern:  or.  t 
operations  and  should  be  available  to  lend  software,  hardware,  and  analytical  support 

i.  No  more  than  h day  every  week  will  be  required  by  the  government  to  comply 
with  mandatory  training  directives.  Scheduling  of  such  training  will  be  accomplish-, 
so  as  to  mini  lime  impact  on  FFTM  operations. 

j.  A general  plan  for  planned  software  corrections  (EPR  related)  and  issue  of 
revised  tapes  is  at  Inclosure  2. 

k.  A general  plan  for  planned  hardware  corrections  (EPR  related)  and  replacer ;r.t 
equipments  is  at  Inclosure  3. 

l.  A general  plan  for  introduction  of  software  changes  to  implement  replacement 
equipments  is  at  Inclosure  4. 

m.  A general  plan  of  currently  planned  contractor  test  efforts  at  Fort  Sill 
and  WSNR  is  at  Inclosure  2. 

n.  Combined  government-contractor  management  reviews  will  be  conducted  on  a 
quarterly  basis  to  determine  progress  toward  DT/OT  11  commencement  and  to  resolve 
problems  that  may  arise.  This  shall  not  preclude  more  frequent  informal  reviews 
that  may  be  required. 

o.  As  a demonstration  that  the  required  work  has  been  accomplished  and  that 
the  system  is  in  fact  ready  for  DT/OT  31  testing  a system  integration  test  will 
be  conducted  at  Fort  Sill,  OK.  Requirements  for  this  testing  are  as  indicated  in 
Contract  Mod  Number  P000S8. 

p.  During  the  FFTM  additional  Operator  and  Maintenance  personnel  training  is 
required.  Opciator  training  will  he  given  via  government  OJT.  DS/GS  Maint  personnel 
are  to  be  trained  by  the  contractor.  All  training  will  be  scheduled  for  mini  mum 
impact  on  the  FFTM.  Place  and  date  of  training  is  to  he  determined,  depending 

on  the  availability  of  personnel  and  equipment.  (Incl  1 for  detail). 
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q.  The  general  plans  described  above  can  be  modified  by  the  1TTM  Control  Team 
on  a case  by  ca sc  basis  vipon  mutual  agreement  between  contractor  and  PMO  AKTADS 
representative. 

EC1  PIC  DLTAJ  LS  : 

1.  The  effort  at  Fort  Fill  will  be  broken  down  into  tvo  parts: 

a.  Part  1:  Contractor  tests 

b.  Part  II:  Government  testing  and  training 

• 

These  parts  will  be  merged  into  one  continuous  schedule  which  will,  based  on  events, 
be  adjusted  by  the  FJTM  control  team, 

2.  Specific  contractor  tests  are  as  indicated  in  Incl  2 to  find  problems  as 
reflected  in  Fort  Sill  EPRs  raid  solutions  thereto.  Other  efforts  will  include 
upgrading  of  equipment  and  introduction  of  new/revised  items. 

3.  Government  testing  will  include  efforts  ‘:o  clear  previous  EPRs,  monitor 
contractor  progress  and  continue  system  eval-ation.  Training  of  OTEA  and  FACd 
personnel  will  be  conducted  as  shown  in  Incl  ’ a 2. 

4.  Personnel  Requirements: 

(a)  Government  - Appropriate  Test  Directors,  operator  and  maintenance  personnel, 
pertinent  test  witnesses  and  evaluators. 

/ ^ C'o  - ^ -\v  . T r*  n *■  a v Cn  ^ f-r  ■ n rn  a n ^ l’ar^'n*-n  f'a’olar^'o  a ’ o f o 

test  being  run,  maintenance  personnel. 

5.  For  DT/OT  II,  the  DivArty  TSS  must  be  re-established  as  a Maintenance  Facility, 
checked  out,  and  made  operational.  Scheduling  and  activities  must  take  this  into 
account . 

6.  The  effort  at  l.’SMR  will  be  broken  down  into  two  parts: 

a.  Part  1 - Contractor  tests 

b.  Part  2 - El’  Runs  and  tape  check-out 

These  parts  will  be  merged  into  one  continuous  schedule  which  will,  based  on 
events,  be  adjusted  as  required  by  the  FFTM  control  team.  An  estimated  8 hours/day, 

5 days/week  run  time  on  the  equipment  will  be  required  to  complete  the  schedule 
by  tlie  lime  the  equipment  must  be  directed  to  other  uses.  The  TSS  DivArty  augmented 
and  one  ET/KST  Bn,  will  be  devoted  to  this  effort.  Should  requirements  arise  for 
training,  deferred  maintenance,  manual  check-out,  or  miscellaneous  needs  separate 
and  distinct  from  the  main  stream  effort:  of  the  2 subparts  described  above,  they 
will  be  undertaken  during  normal  shift  operations  on  a non  - in terf or ing  basis  or  be 
deferred  to  a special  separate  shift. 
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7.  Contractor  tests:  Specific  software  check-outs  as  indicated  at  Incl  2 to  find 
problems  as  reflected  in  W.1MR  ElT.s  and  solutions  thereto.  Other  efforts  will 
include  upgrading  of  equipment  and  introduction  of  new/revised  items. 

El'  Runs  and  Tape  check-out.  On  the  operations  side,  FSE , COMSEC  (ITCl/lCD), 
tape  check-out  and  selected  portions  of  1UT.T  arc  to  be  accor.pl  i shed . Hardware  tests 
in  DIP , shelter  drop  and  S-2S0  Load  have  yet  to  be  performed.  Finally,  some  ET 
requirements  for  newly  introduced  devices  or  for  reruns  due  to  changes  wrought  by 
configuration  alterations  may  have  to  be  addressed.  While  emphasis  is  placed  on  the 
FSE/COMSEC/LURT  tests,  scheduling  must  provide  for  accomplishment  of  the  remainder. 
To  preclude  impact  during  the  latter  stages  of  FFTM  and  on  LU/OT  11,  DIP  should 
immediately  be  accomplished.  The  DIP  test  will  be  run  under  restrictive  'conditions 
to  be  supplied  by  the  contractor  v.’hich  will  limit  the  possibility  of  catastrophic 
failure.  Emphasis  will  then  be  placed  on  COMSEC/F  SE./LD  T runs  with  the  remaining 
tests  integrated  into  the  schedule. 

9.  Personnel  Reouircr ents. 


a.  Government  - Appropriate  Test  Directors,  operator  and  organizational 
maintenance  personnel,  pertinent  test  witnesses  and  evaluators. 

b.  Contractor  - Test  Director,  Software  and  Hardware  specialists  appropriate 
to  test  being  run,  DS/GS  maintenance  personnel. 

10.  It  should  be  noted  that  the  DTM  reorganization  and  Litton  training  have  not 
been  contracted  for  as  of  this  date. 


HAROLD  J.  ELLERS  DUANE  L.  E'.ERSON 

TACTIRE  Program  Manager  Colonel , GS 

Litton  DSD  Representative  Director,  TACF1RE 


Contracting  Officer's  Representative 
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APPENDIX  D 

LIST  OF  ACRONYMS 


ADFSC 

Automatic  Data  Field  Systems  Command 

ADP 

Automatic  Data  Processing 

ADSAF 

Automatic  Data  Systems  for  Army 

in  the  Field 

AMC 

Army 

Materiel  Command 

AMSAA 

Army 

Materiel  Systems  Analysis 

Agency 

AR 

Army 

Regulation 

ARTADS 

Army 

Tactical  Data  Systems 

AS  ARC 

Army 

Systems  Acquisition  Review 

Council 

CCI3 

CDC 

CDR 

CG 

COEA 

CORADCOM 

CPFF 

CRT 

CSC 

CS3 


Command  and  Control  Information  Systems 
Combat  Developments  Command 
Critical  Design  Review 
Commanding  General 

Cost  Operational  Effectiveness  Analysis 

Communications  Research  & Development  Command 

Cost  Plus  Fixed  Fee 

Cathode  Ray  Tube 

Computer  Systems  Command 

Combat  Service  Support  System 
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DA 

DARCOM 

DCP 

DDR&E 

DDT 

DIYARTY 

DMD 

DOD 

DS 

DSARC 

DT 


Department  of  the  Army 
Development  and  Readiness  Command 
Development  Concept  Paper 

Defense  Director  of  Research  and  Engineering 

Digital  Data  Terminal 

Division  Artillery 

Digital  Message  Device 

Department  of  Defense 

Direct  Support 

Defense  Systems  Acquisition  Review  Council 
Development  Test 


ECOM 

ECP 

EPR 

EST 

ET 

ETD 


Electronics  Command 
Engineering  Change  Proposal 
Equipment  Performance  Report 
Expanded  Service  Test 
Engineering  Test 
Electronic  Tactical  Display 


FAA 

FADAC 

FAT 

FDTE 

FFMED 


Field  Artillery  Agency 

Field  Artillery  Digital  Automatic  Computer 
First  Article  Test 

Force  Development  Test  and  Evaluation 
Fixed  Format  Message  Entry  Device 
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FIELDATA 

FORSCOM 

FQT 

FSDR 

FSE 

FSP 

GAO 

GS 

LP 

LRIP 

MCMU 

M&D 

MOD 

MTBF 

MTTR 

OD 

OS 

OSD 

OT 

OTEA 


Field  Data 
Forces  Command 
Formal  Qualification  Test 
Functional  System  Design  Requirement 

Fire  Support  Element 

% 

Full  Scale  Production 

General  Accounting  Office 
General  Support 

Limited  Procurement 

Low  Rate  Initial  Production 

Magnetic  Core  Memory  Unit 
Maintenance  & Diagnostic 
Modi f icat ion 

Mean  Time  Rptwppn  failures 
Mean  Time  to  Repair 

Operational  Deficiency 
Operating  System 

Office  of  the  Secretary  of  Defense 
Operational  Test 

Operational  Test  and  Evaluation  Agency 
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PDR 


PM 


PQT 

PRC 

PSSA/B 


Preliminary  Design  Review 
Project  Manager 

Preliminary  Qualification  Test 
Planning  Research  Corporation 
Programming  Support  System  A/B 


QMR 


Qualitative  Materiel  Requirement 


RAM 

R&D 

RDAT 

RECAP 


Random  Access  Memory 
Research  and  Development 

Research  and  Development  Acceptance  Testing 
Review  and  Command  Assessment  of  Projects 


SAR  Selected  Acquisition  Report 

SRB  Software  Review  Board 

SSEB  Source  Selection  Evaluation  Board 


TACFIRE  Tactical  Fire  Direction  System 

TACVA^  Tactical  User  Validation  Committee 

TECOM  Test  and  Evaluation  Command 

TIWG  Test  Integration  Working  Group 

TOS  Tactical  Operations  System 

TPP  Total  Package  Procurement 

TRACATA  TRADOC  Combined  Arms  Test  Activity 

TRADOC  Training  and  Doctrine  Command 
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TRASANA 

TSM 

USAAMS 

USACGSC 

USACONARC 

USAEPG 

USAREUR 

UDI 

WSMR 


TRADOC  Systems  Analysis  Agency 
TRADOC  Systems  Manager 

US  Army  Artillery  and  Missile  School 

US  Army  Command  and  General  Staff  College 

US  Army  Continental  Army  Command 

US  Army  Electronic  Proving  Grounds 

US  Army  Europe 

User  Determination  Item 

White  Sands  Missile  Range,  NM 
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